I think it is complete for Review. But: What ist the Plan for new Features? Or Plans for Prototype Applications? I see they are disabled in this install and there is no Calendar Project. If the Priority is to get Phorge rebrand and related Things done first, this diff can safely lay around until Things are sorted.

the only global config option I can find is the timezone, so either way changes to phorge core would be required. Timezone has no default value. (It's typically controlled by the php date.timezone setting)

Hey everyone, I just learned about the Phabricator situation and I'd love to contribute to the project in any capacity I can. I've been around the discourse for some time and love Phabricator to bits and would love to keep it and see it thrive again!

(by the way, this task was intended to the Phorge tracker, not for the Phorge project tracker if both will be maintained separately)

In T15035#1086, @MacFan4000 wrote:

Matrix - not sure

For irc there is Phorge on Libera.chat. I’ve submitted a ticket for community registration after speaking with staff, but I haven’t heard back. (Ticket was submitted 3 weeks ago). Matrix - not sure

I think this looks good, and based on the (non-search-engine) conduit API stuff I'm familiar with I think everything looks correct.

• reflow

• add additional constraints as requested

Is there information about the IRC channel or Matrix channel on how to get set up? If there's chat I'll try to join in but I won't be able to be always-connected.

I added you both as well! Welcome to the team. If anyone has pre-existing functionality that they feel would be good to include in the upstream feel free to submit the changes. There's ongoing work (unfortunately slowly) to rebrand the project, but that's not holding up other changes at this time.

In D25015#633, @avivey wrote:

In this case I think the error text is agnostic of the instance of the dialog.

I was thinking about this use-case, which implies to me that the dialog author should be involved in the error text:

For the case of email headers

In https://secure.phabricator.com/T13658#256009, @epriestley wrote:

One other case where "Phabricator" appears is in HTTP and Email headers, e.g. X-Phabricator-XYZ. For a separate project wanting to update these I think a slow migration approach is needed, to allow recipients currently expecting the existing fields. I'm guessing there isn't a reasonable change here for the upstream.

Depending on how many of these we end up with, I think an email-header-prefix sort of config option might be reasonable.

Leave the default storage namespace as phabricator

I like the idea of having an easily greppeable token...

what about egrohp? ("phorge" backwards)?

Does anyone like, not like, or have additional thoughts on the general idea of making one or more unique identifiers that isn't "phorge", for the purpose of an identifier that is unmistakably greppable? I outlined some notes on this idea here: T15006#831

Per https://we.phorge.it/source/phorge/manage/policies/ the push policy for this repo is set to Blessed Committers

In D25014#624, @MacFan4000 wrote:

Could a member of Blessed Committers please land this? I can't do it my self (no write access) and I would appreciate it.

Ok my implementation had a couple of additional search constraints which are missing here. Otherwise this looks good to me and is more complete. I'll probably abandon my patch and apply this one if you don't mind including the additional search constraints. (See suggested edits.)

FWIW here is my implementation which overlaps somewhat:

What are the implications of making changes to the javelinjs.com https://github.com/phacility/javelin/ library?

I'd be happy to contribute. I currently maintain an installation with over 4,000 git repos and over 2,000 users since 2016. Our company apparently had the highest karma count by a wide margin with our Phacility Support Pact, for whatever that's worth :)

• DRY up LegalpadDocumentSignature::generatePHID()

Could a member of Blessed Committers please land this? I can't do it my self (no write access) and I would appreciate it.

I would also love to contribute to Phorge. I have signed the legalpad doc.

Also I don’t believe javelin.io is related to the Javalin used in Phab.

Ah I did not look closely enough. Dang. We should be attaching the message to the view on the server then, somehow.

Oh, another potential concern...

In D25015#616, @speck wrote:

In this case I think the error text is agnostic of the instance of the dialog. From looking at AphrontDialogView I didn't see any obvious way to include additional fields/text that could be pulled out here on the front end. Looking elsewhere in this file (line ~297) it looks like some other generic text is used

if (!this._paused) {
  JX.$E('Resuming a workflow which is not paused!');
}

However that's the only case where JX.$E is used outside of an is-development check. I'm not sure where these Javascript translations would go or when the translation file is generated.

To be fair, I'm almost certainly not going to install yet another client just for this community chat. (I know I'm not alone in this, projecting forward into the project's future.) Matrix + IRC with bridges to the other protocols seems the way to go. (I'm usually on IRC...albeit, not much this month because my plate's full.)

This looks good to me.

I added @dcog @codemouse92 and @mydeveloperday to the trusted contributors group. Glad to have everyone involved!

In this case I think the error text is agnostic of the instance of the dialog. From looking at AphrontDialogView I didn't see any obvious way to include additional fields/text that could be pulled out here on the front end. Looking elsewhere in this file (line ~297) it looks like some other generic text is used

if (!this._paused) {
  JX.$E('Resuming a workflow which is not paused!');
}

I'm not familiar with the search engine or legalpad frameworks but things look like they line up

@roguelazer - added you to Trusted Contributors so you should be able to land now

FWIW, I can't land this myself since I don't have push access to any repos; I would appreciate it if someone would either land it (or give me such permissions, if that's the preference).

Wow, this is something I developed for wikimedia but not nearly as extensive! I'll try to give some code review when I have a few minutes to look this over.

+1 this has bitten me before.

Not sure if this is where to mention, I would definitely like to help develop/maintain/review Phorge (I have signed the doc), I currently maintain a 600+ user Phabricator instance housing 50+ git repos,

• Be quiet Linter!

• Move Links and Names to Variables

The ubuntu/rhel scripts have been removed in the upstream (https://secure.phabricator.com/D21678). We can probably avoid making changes to those files as they should go away once we merge in changes.

In T15010#1062, @avivey wrote:

Any user should be able to sign the doc at L1 Phorge Vision Statement - did you try it and got an error?

In T15010#1060, @codemouse92 wrote:

I agree with the doc, and would like to sign too.

Glad to see Phabricator continuing as Phorge. Not going to lie, I had a panic attack this morning when I found out that Phacility was winding down.

The arcanist source in general seems to be split between fwrite(STDERR, $message."\n") and fprintf(STDERR, "%s\n", $message); I decided to go with the latter.

I think the latter format would be preferred as the formatting is more common elsewhere in the code, as opposed to concatenation.

And for google you don't need to provide an email, you can also just get a gmail address.

@speck we can use the existing GitHub organization for oauth. (an owner can setup the app in settings)

I think this would be reasonable but I think it requires setting up an account on GitHub or Google on behalf of Phorge (rather than using a member's personal account). If someone wants to set up a GitHub/Google account for phorge we can set it up here. It'll require an email address though and I'm not sure how to handle an organization email like that.

I can help out with upstream merges. I've been doing it on a regular basis for Wikimedia for a long time now. It's rarely been a problem but I'm been careful to make sure that Wikimedia's fork doesn't drift too far away from upstream.

Just as a note, All of the mentioned chat platforms can be bridged together.

I'm not a big fan of IRC because in order to look through history or pickup where a user last joined it requires individual users to maintain their own tooling/practices. The temp-community chat was the first Zulip chat that I've used, and installed the mobile app for. I thought Zulip worked pretty well and wouldn't mind continuing with that. I've used Matrix (Element?) briefly but didn't feel too strongly about it. It's probably worth mentioning that our current Zulip instance has ~135 members and we've still had ~1-2 new people join per week lately. Though there's not much actual discussion going on there.

Handling of merging upstream changes will probably lead to some challenging merges done by people who did not author the original changes in Phorge. I don't know what the best way is to work around this. Maybe if we regularly (daily?) pull in changes from upstream, merge into our own master branch which everyone lands onto that should mostly catch merge issues?

We don't seem to have any opposition to having a community/support IRC channel, so perhaps I'll start working with Libera staff on registration.

I just want everything "important" to be happening here, where the search and cross-references works and async communication is easy.

I prefer IRC but don't have any issues with having Matrix bridged there, but I would prefer to not have separate unbridged channels to reduce fragmentation of the already-small community.

In T15035#1019, @TitanNano wrote:

Are there any thoughts about a matrix channel? It would also be possible to bridge it to IRC.

In T15035#1019, @TitanNano wrote:

Are there any thoughts about a matrix channel? It would also be possible to bridge it to IRC.

Are there any thoughts about a matrix channel? It would also be possible to bridge it to IRC.

The translated text can be a property of the dialogue itself, if we're worried about having extra objects laying around - the confirmation feels like it's a feature of the dialogue anyway.

There's no way to invoke pht from JS (because it's really complicated in the general case). The general practice is to provide the translated value from PHP when building the relevant objects. There should be an example in the UIExamples app - there's a page with buttons built in JS.

There already are a bunch of worthwhile changes in Phabricator we should pick up; @Matthew - want to load them to check out the procedure? I can do that otherwise.

In D25015#539, @Ekubischta wrote:

I 100% agree with this. Is there no way to invoke internationalization via JS only? If not, that's perfectly great, but wondering about an answer offhand.

In T15001#1011, @MacFan4000 wrote:

In T15001#980, @MacFan4000 wrote:

Just a note that Trusted Contributors can’t self grow beyond admins adding people currently as to add members you need to be able to edit the project. Currently only admins can edit the project.

IMO the edit policy should be set to Project Members. This way it’ll be able to self grow. :)