Change Details

"Phabricator" and "Phacility" are trademarked names, and the logo is copyrighted. To start an initial fork we need update the source code and remove references which identify the product as Phabricator in order to abide by trademark/copyright laws and expectations. This particularly needs to be done so that changes to the product are clearly reflected as being work done by Phorge community/organization and not Phabricator/Phacility. EvanP has communicated that he would be willing to accept an upstream patch that makes the branding of the site configurable/convenient. The primary diffs which pull out mentions of "Phabricator" and "Phacility" should be done in a means that it would be accepted upstream. The ideal strategy for this looks roughly like: 1. Extract out the words "Phabricator" and "Phacility" from user-visible strings, in both rP and rARC , to instead pull the project name and organization from a single static method (one method in rP which pulls the hard-coded value defined in rARC). 2. Leave the hard-coded values as "Phabricator" and "Phacility" 3. Submit the change upstream to Phabricator 4. Everything goes perfectly and the changes are adopted 5. Pull in the accepted changes from upstream 6. Replace the project name, organization name, and the logo/favicon with Phorge-branded assets 7. Complete. --- Various places identified as indicating "Phabricator" - [ ] Various places in the settings - [ ] Auth app - [x] Diviner mentions Phabricator in the command line example for building docs and additionally calls it Phabricator documentation - Marking as completed because this is being addressed by {T15012} - [ ] Emails mention Phabricator in various subjects, bodies and sender names - [ ] Logo, Phorge-branded assets to be created via {T15005} - [ ] `./NOTICE` has some legal text we might need help with. - [ ] Emails have a bunch of `X-Phabricator-*` headers, for configuring rules in mail clients. - We may want to allow installs to keep it as `Phabricator` for compatibility - [ ] `PhabricatorAphlictManagementWorkflow.php` has several hard-coded paths assuming the project is checked out under the directory name of `phabricator`, which will need changed to checking `phorge` first and then `phabricator` if it doesn't exist, otherwise installing Aphlict will fail to locate the default configuration file for anyone starting from a fresh install vs. updating their existing checkout. - [ ] `PhabricatorDaemonsSetupCheck.php` creates several setup issues with `.addCommand('phabricator/ $ ./bin/phd ...')`. I believe this is just text that is displayed to the admins of a site however the `phabricator/` here represents the repository of the project. This along with the above issue related to Alphict assuming `phabricator` as a directory name we may need to extract out a similar "project repo name" to be used in these places.

"Phabricator" and "Phacility" are trademarked names, and the logo is copyrighted. To start an initial fork we need update the source code and remove references which identify the product as Phabricator in order to abide by trademark/copyright laws and expectations. This particularly needs to be done so that changes to the product are clearly reflected as being work done by Phorge community/organization and not Phabricator/Phacility. EvanP has communicated that he would be willing to accept an upstream patch that makes the branding of the site configurable/convenient. The primary diffs which pull out mentions of "Phabricator" and "Phacility" should be done in a means that it would be accepted upstream. The ideal strategy for this looks roughly like: 1. Extract out the words "Phabricator" and "Phacility" from user-visible strings, in both rP and rARC , to instead pull the project name and organization from a single static method (one method in rP which pulls the hard-coded value defined in rARC). 2. Leave the hard-coded values as "Phabricator" and "Phacility" 3. Submit the change upstream to Phabricator 4. Everything goes perfectly and the changes are adopted 5. Pull in the accepted changes from upstream 6. Replace the project name, organization name, and the logo/favicon with Phorge-branded assets 7. Complete. --- Various places identified as indicating "Phabricator" - [ ] Various places in the settings - [ ] Auth app - [x] Diviner mentions Phabricator in the command line example for building docs and additionally calls it Phabricator documentation - Marking as completed because this is being addressed by {T15012} - [ ] Emails mention Phabricator in various subjects, bodies and sender names - [ ] Logo, Phorge-branded assets to be created via {T15005} - [ ] `./NOTICE` has some legal text we might need help with. - [ ] Emails have a bunch of `X-Phabricator-*` headers, for configuring rules in mail clients. - We may want to allow installs to keep it as `Phabricator` for compatibility - [ ] `PhabricatorAphlictManagementWorkflow.php` has several hard-coded paths assuming the project is checked out under the directory name of `phabricator`, which will need changed to checking `phorge` first and then `phabricator` if it doesn't exist, otherwise installing Aphlict will fail to locate the default configuration file for anyone starting from a fresh install vs. updating their existing checkout. - [ ] `PhabricatorDaemonsSetupCheck.php` creates several setup issues with `.addCommand('phabricator/ $ ./bin/phd ...')`. I believe this is just text that is displayed to the admins of a site however the `phabricator/` here represents the repository of the project. This along with the above issue related to Alphict assuming `phabricator` as a directory name we may need to extract out a similar "project repo name" to be used in these places. - [ ] `PhabricatorPHPPreflightSetupCheck` creates a setup issue which includes a link using `https://phurl.io` -- these Phurl links will direct to content hosted on `secure.phabricator.com`. I'm not sure what to do about these. In this case the content being linked to is https://secure.phabricator.com/T12101. We probably need to extract the content into a Diviner doc and link to that instead? Looking at some of the other setup issues linking to docs/content it looks like there's a way to do this via `PhabricatorEnv::getDoclink('Managing Daemons with phd')` which I'm assuming links to https://secure.phabricator.com/book/phabricator/article/managing_daemons/.

"Phabricator" and "Phacility" are trademarked names, and the logo is copyrighted. To start an initial fork we need update the source code and remove references which identify the product as Phabricator in order to abide by trademark/copyright laws and expectations. This particularly needs to be done so that changes to the product are clearly reflected as being work done by Phorge community/organization and not Phabricator/Phacility. EvanP has communicated that he would be willing to accept an upstream patch that makes the branding of the site configurable/convenient. The primary diffs which pull out mentions of "Phabricator" and "Phacility" should be done in a means that it would be accepted upstream. The ideal strategy for this looks roughly like: 1. Extract out the words "Phabricator" and "Phacility" from user-visible strings, in both rP and rARC , to instead pull the project name and organization from a single static method (one method in rP which pulls the hard-coded value defined in rARC). 2. Leave the hard-coded values as "Phabricator" and "Phacility" 3. Submit the change upstream to Phabricator 4. Everything goes perfectly and the changes are adopted 5. Pull in the accepted changes from upstream 6. Replace the project name, organization name, and the logo/favicon with Phorge-branded assets 7. Complete. --- Various places identified as indicating "Phabricator" - [ ] Various places in the settings - [ ] Auth app - [x] Diviner mentions Phabricator in the command line example for building docs and additionally calls it Phabricator documentation - Marking as completed because this is being addressed by {T15012} - [ ] Emails mention Phabricator in various subjects, bodies and sender names - [ ] Logo, Phorge-branded assets to be created via {T15005} - [ ] `./NOTICE` has some legal text we might need help with. - [ ] Emails have a bunch of `X-Phabricator-*` headers, for configuring rules in mail clients. - We may want to allow installs to keep it as `Phabricator` for compatibility - [ ] `PhabricatorAphlictManagementWorkflow.php` has several hard-coded paths assuming the project is checked out under the directory name of `phabricator`, which will need changed to checking `phorge` first and then `phabricator` if it doesn't exist, otherwise installing Aphlict will fail to locate the default configuration file for anyone starting from a fresh install vs. updating their existing checkout. - [ ] `PhabricatorDaemonsSetupCheck.php` creates several setup issues with `.addCommand('phabricator/ $ ./bin/phd ...')`. I believe this is just text that is displayed to the admins of a site however the `phabricator/` here represents the repository of the project. This along with the above issue related to Alphict assuming `phabricator` as a directory name we may need to extract out a similar "project repo name" to be used in these places. - [ ] `PhabricatorPHPPreflightSetupCheck` creates a setup issue which includes a link using `https://phurl.io` -- these Phurl links will direct to content hosted on `secure.phabricator.com`. I'm not sure what to do about these. In this case the content being linked to is https://secure.phabricator.com/T12101. We probably need to extract the content into a Diviner doc and link to that instead? Looking at some of the other setup issues linking to docs/content it looks like there's a way to do this via `PhabricatorEnv::getDoclink('Managing Daemons with phd')` which I'm assuming links to https://secure.phabricator.com/book/phabricator/article/managing_daemons/.