For this diff I'm going to continue the current approach of swapping Phabricator with %s and adding an argument, with the understanding that this might not be the final approach we take.

I took a bit of a further look and this does look like a solid refactor. I think in general we should also aim to add more documentation as we go along which will help to improve others' understanding of how things function. Since there's a lot of existing code that's undocumented I think adding class-level and method-level comments to any which are added or significantly refactored would be good to add for this.

In D25012#422, @Ekubischta wrote:

We could move this from the global exclude to just the specific linters (like the txt linter, etc.) - That would be a reasonable request

D25012 solves it, but I wonder if we should just exclude it from the "type": "text" linters

We could move this from the global exclude to just the specific linters (like the txt linter, etc.) - That would be a reasonable request

ahh, there's a global setting for revisions - differential.generated-paths.

I was thinking of ArcanistGeneratedLinter.php, but it looks like the only way to mark a file is by adding @generated in it, and I think we can't do that?
I thought there was another way, because this also applies to revisions (it folds the file by default).

In T15021#564, @avivey wrote:

There might be a way to explicitly define it as generated, which (used to) exclude it from lint.

In D25002#410, @avivey wrote:

In D25002#406, @Ekubischta wrote:

Could we...

1. Create a new Translation which specifically translates the token : e.g. %PHAB or {{Phabricator}} or {{PhabricatorWordmark}} or whatever

https://we.phorge.it/source/phorge/browse/master/src/infrastructure/internationalization/translation/PhabricatorUSEnglishTranslation.php has a few more instances of Phabricator (not in pht()).

Thank you for checking out an example CircleCI, both with and without these changes! That gives a lot of confidence that these changes are pretty stable. I just did a quick look through the code changes but would like to sit down later and go through more in-depth if only to learn more about Harbormaster.

(I'm 100% with @speck on requiring tasks)

@deadalnix's I like option 3 from a UX perspective - and it also lets us hold on this issue for a little while, without making things worse.

I think it makes sense to find some balance based off the impact of a change. If someone is submitting some code documentation changes or typos then I would personally be fine with not requiring a task as long as the diff itself can encompass the details and lints/unit-tests to account for syntax errors. What I'm worried about are larger changes which don't have tasks, as that means someone is putting time into larger changes without seeking input/discussion from others about how to approach the problem. Additionally it may also be possible that someone else is working on a similar change resulting in either duplicated or conflicting efforts.

Could we...

I am not a fan of adding interaction to the upgrade process but we can use the "setup issues framework" or an approach similar to @deadalnix's comment.

I like the proposal above. Especially with having the core team "sign" a vision statement. The goal is less legalistic and more of ensuring we have a consistent view of the end product.

In T15008#651, @speck wrote:

@jupe yea I figure similar to the Phabricator landing page on https://phacility.com/phabricator/ I think we want a basic static page which showcases the project & features, along with some form of T15010, then points to the other content on this install.

In T15008#619, @deadalnix wrote:

In T15008#573, @jupe wrote:

should we also start working on the content?

Yes. If there is something that is obviously useful and that you know how to do, then please do it. You'll be adding a ton of value.

Definitely -- I believe the idea that @avivey is aiming for is something extending AphrontSite which would serve up this static page/content, then we can update nginx to point phorge.it to that site leaving we.phorge.it to point here. If you'd like to start putting together the content or learning about extending AphrontSite that would be a great help.

I had a thought, that adding a %xx argument to pht without matching argument is probably not a really good idea, so I went exploring.

In T15014#676, @Ekubischta wrote:

A few final thoughts here as well

• Phorge was branched from Phabricator and T15000 was created 14 days ago - This is barely enough time to figure out some basic setup and infrastucture stuff let alone develop the strategy for an entirely new open source software project. Even further than this, this is forked from an already existing and stable project It is completely prudent to keep the brakes on for a sec while this stuff gets figured out

• Tasks before diffs...always... The task describes the issue and one or more revisions resolves this issue. The lift requred to create a task is so minimal that I am surprised that this is a point of contention

1. Create a task
2. Create a branch in form of Txxx-BranchName
   • Your revision will be automatically linked to the task - no manual work
3. Write your revision and comment Fixes Txxx in the summary
4. When you land your revision - Task is automatically closed

In fact, once arc work is completed for task handling, you can do arc work Txxx from the cli and it automatically creates the branch - simple and easy

What would be immensely worse, is a process that says "If the developer does not feel a task is required, then don't make one" - This is chaos.. If you have 10 developers, you will have 10 different versions of "when is a task required?" - This is solved simply by saying : "Make a task describing the issue, attach your revision to it"

, if one is to fix a typo in a comment, requiring that person to open a task, then open a diff linked to the task, than mark the task as resolves once the diff is landed would actually be harmful.

How? - Again, the work required to create a task is so minimal - We have literally spent more time discussing "should we create a task" then the time it takes to create 100 tasks

So I setup an instance and a dummy project with CircleCI integration.

What can I do to Help? -

A few final thoughts here as well

Great! Thanks @Matthew .

In T15004#672, @speck wrote:

I would say let’s go ahead and make those changes. I’ll be on later tonight from a workstation and can make those changes then (~8hrs) if needed.

I didn't talk with him in a while. Maybe opening a ticket in secure.phabricator.com is the quickest way?

In T15014#671, @avivey wrote:

In T15014#670, @deadalnix wrote:

Now, can we get a setup with CircleCI going so that we can test things?

Everybody else is busy with the rebrand/startup process. You should be able to create a free account and test from your own environment - I think that's how Evan developed it originally.

@avivey has anyone been in contact with Evan that can reach out? I don’t really know of a way to reach him for this type of topic/project.

I would say let’s go ahead and make those changes. I’ll be on later tonight from a workstation and can make those changes then (~8hrs) if needed.

In T15014#670, @deadalnix wrote:

Now, can we get a setup with CircleCI going so that we can test things?

In T15014#622, @speck wrote:

I'm redirecting the discussion from D25011 to this task

I second everything @speck says here.

@speck What you have here seems reasonable to me. Can you propose this upstream and see how it goes?

I like the {Phabricator} idea! For technical compatibility with the rest of pht, it should probably be something like %PH.

Okay I was able to run lints properly but running unit tests still failed because I'm not running a proper dev environment yet. I'll definitely get this done before considering this change for landing/submission though.

Still need to nuke the 500 Phabricators

• Move the project and org definitions to PhabricatorPlatformSite methods
• Update existing references to moved place
• Fix the default wordmark so it's not immediately translated via pht()

Just to add clarification around T15009: Evaluate legal organization format ("Foundation"), we can opt to create our own organization instead of joining an existing foundation however that involves a lot more paperwork, submissions, legal stuff, etc. The foundations are a means for speeding along that process, where Apache Foundation, Linux Foundation, etc. create their own non-profit organizational legal entity then "adopt" sub-projects which automatically inherit and become part of their entity as long as we abide by their agreements, largely focused around providing open source projects run by open source communities. In turn they provide benefits like being the actual legal entity that owns the trademarks/copyrights/assets for the project, some even offer to be owner of domain names etc. along with providing some legal assistance for e.g. open source license law or even for initially acquiring trademarks/copyrights.

In T15004#650, @speck wrote:

This is my understanding of the items in the description currently, please indicate if this is not correct

Security - I think this may have originally been intended for tagging items which are related to security issues that need addressed, such as vulnerabilities in the project. I think this is a tag that anyone could use when submitting issues.
Security Viewers - This is used to wall off items that should be restricted from public viewing, namely security reports, putting things into {S2}
Blessed Committers - The group of people who can push changes to the upstream

@jupe yea I figure similar to the Phabricator landing page on https://phacility.com/phabricator/ I think we want a basic static page which showcases the project & features, along with some form of T15010, then points to the other content on this install.

This is my understanding of the items in the description currently, please indicate if this is not correct

I'm redirecting the discussion from D25011 to this task

In T15008#573, @jupe wrote:

should we also start working on the content?

How many of them are there? Eyeballing P2, it's of the order of 500. There are 5 people in this task, we can do 15/day and be done in a week. That doesn't sound intractable if we are all willing to chip in.

In D25011#376, @jupe wrote:

To add my two cents on this:

Of all the point raised, only the one about testing seems to fall in the category of good process, and even then, the part on unit tests still kind of falls in the wrong bucket

I have the feeling that the issue at hands is a different perception of priorities. I agree with you on the fact that we should be goal oriented: right now different people might have different goals in mind.

In D25011#370, @avivey wrote:

@deadalnix: want to move the bigger discussion to a ny task? I'm on a mobile right now.

Cool script @avivey! - I ran it (see P2) and see that we have a large task at hand...

Running ./bin/i18n extract . and then this scripts, shows 455 strings with the words Phabricator or Phacility (1 for Phacility), plus 19 in arcanist.

This is roughly what I was planning on

1. Move PhabricatorApplication::PROJECT_APPLICATION_NAME into PhabricatorSite::getName() (I have a local change for this)
2. Update all existing PhabricatorApplication::PROJECT_APPLICATION_NAME uses to PhabricatorSite::getName() (I haven't yet done this, still figuring out best tooling/environment for PHP development)
3. Update PhabricatorCustomLogoConfigType::getDefaultWordmark() to not use pht() but instead have the callers wrap the result in pht().
4. Grep for Phabricator and Phacility appearing anywhere within single or double quotes. Likely need to exclude celerity-generated files. Replace with PhabricatorSite::getName()
5. Create PhabricatorSite::getProjectOrg() to return Phacility if it's needed from #4

In D25002#144, @speck wrote:

Still need to search for instances of Phabricator appearing anywhere within quotes. Testing all this will be fun.

How can I help?
Are we down to just grepping, or is there still some design left to do?

To add my two cents on this:

I did skip lint and unit tests for now as I could not get them working properly on my system (something blew up trying to connect to MySQL). I will be setting up a proper development environment at some point.

It says "Lint/Unit were skipped" for this diff - did you actually "skip" them, or is this some setup/usage artifact?