I'm setting the "Moderate" policy on Ponder to Trusted Contributors and I'll add a link to Ponder from the default home page.

Some initial findings on Rector...

As discussed in {E2}, we might add temporary banners to Diviner to state that we are rebranding. This would allow some time for us to handle the code rebrand and address the underlying Diviner issues before we edit everything twice.

As discussed in {E2}, we will be implementing this to control spam for now. If this doesn't work, we will revisit this discussion.

In T15012#1283, @MacFan4000 wrote:

I will note that also the tech docs aren’t fully generated since there should be docs for most of the phorge/phabricator classes. Also the arcanist docs aren’t generated at all.

Alright, I've just went through a similar process - they apparently have changed their process a little but there still is a form to fill out: https://support.microsoft.com/en-us/getsupport?oaspworkflow=start_1.0.0.0&wfname=capsub&productkey=edfsmsbl3 (you need a Microsoft Account to fill it out, but they'll contact you on the contact email you give in the form)

Obviously spam.

Reordering milestones is convenient when you want to treat milestones as workflow steps rather than sequential numerical versions.

In T15082#2028, @golyalpha wrote:

epriestley was very much against this idea but wikimedia's users loved it.

Do we have epristley's reasoning as to why he was against this? Might help in deciding about including this patch in Phorge.

Since all changes are going to be submitted to the upstream prior to landing here in Phorge it would be easiest if changes were made to a clone of Phabricator and not a clone of Phorge.

epriestley was very much against this idea but wikimedia's users loved it.

Thanks for your comments! Namespacing might be useful, we would have to figure out what that looked like. I was thinking "/book/group/link" as that would be pretty natural (and is very close to what Diviner does already: "/book/group/filename"). It would also allow for us to eventually make Diviner widely useful, see secure: T4558. However, that is a broader discussion that should probably wait...

A few thoughts. This sounds like a great idea as searching by article title seems a little fragile as you mention. I think a good practice for using the proposed @link would be to fully namespace it somehow like @link development.processes.i18n, though I'm not totally sure what that looks like as I'm not familiar with the Diviner format or structure. If we have the use of namespaces then managing multiple @link declarations might lead to confusion or tedious to maintain. To me this also feels more similar to something like an @id rather than @link. What are your thoughts?

A highly unfortunate side-effect of T15077: Rebrand: Tracking task is that it will invalidate a ton of translations. My guess is that upstream did not want to maintain these translations as part of the release product, possibly due to not requiring translations be part of the Phabricator release process. If we pull them into the Phorge codebase then we would likely need to update all translations for any text changes made during development, prior to release. I think it would make sense to host the translations in a repository here but I would worry about them quickly falling out of date. Handling of translations is likely a larger-sized project that we would need help managing.

As part of {E1} we reviewed this as a priority item, and have created T15077: Rebrand: Tracking task for concrete first steps forwards. There is a lot of text to update and review and that task is setup with instructions on how we're approaching it as well as listing out all the individual applications to update. Anyone interested in assisting please review that task and feel free to put your name on an application/folder, as well as ask any questions for clarification.

I put up some coding guidelines that I could recall from when I was working with upstream on example changes. I won't be back at my home office for another week so there may be some things I'm missing but I think a number of things were covered/discussed with Evan on the example changes in https://secure.phabricator.com/D21712.

I am closing this, future meetings are scheduled now. See March 21, 2022 for more information.

In T15080#1970, @speck wrote:

Unfortunately this type of issue is in an area that's beyond my network/configuration experience. Is CloudFlare our NS provider?

What you're talking about is more like mTLS (mutual TLS), that's not actually how WebAuthn works. (Though supporting mTLS for sign-ins might also be something worth looking into)

• e95157e39bf5 Show matching context from the document body in ferret search results
  • This is not perfect but it generally works - display a snippet from the matched document and highlight the matched words - kind standard and expected from any full-text search engine. Probably not my best work as far as code quality / it's a bit hacky and performance may not be stellar, however, it's been in use at wikimedia for quite some time without any major issues that I'm aware of.
• bba62cf52435 Hide the "hidden" fields on custom form previews.
  • This is a single line change to css that makes things a lot cleaner when you have a lot of custom forms with a lot of custom fields.
  • submitted as D25037
• 9191d4838278 Make "task type" and date-type custom fields work in herald.
• 3d33d1cceac7 Implement Atom/RSS discovery on Phame blog pages
• ebfe30890b52 Add column sequence to the conduit api results for column.search
  • This seems like an obvious omission from the conduit api for columns and the change is straightforward.
  • submitted as D25038
• 893664bd44b8 EditEngine: 'Duplicate Form' action to create new forms from existing config.
  • This makes it much easier to clutter up your custom forms with 100 variations of your forms. It also makes it much easier to make a new form vs. starting from scratch every time. It's sort of a hack and the custom form management UI needs a lot of improvement generally, this was just the minimum change I could implement to make life slightly easier for myself and fellow Wikimedia phab admins. Not sure it's a good idea in the upstream without further changes to go with it.
• 44a94dc04b3f Fix validation of "column" transaction type in "maniphest.edit"

fwiw, this is how I handled it in the wikimedia fork:

Ah interesting. My own preference would be updating PhabricatoPeopleProfileController as I would associate this more as a view-level change but looking again at how this is structured I don't think it would cause any issues and I don't feel too strongly about changing it.

In D25035#1059, @speck wrote:

Real quick before landing -- should this change be made here in PhabricatorUser or would it be sufficient in PhabricatorPeopleProfileController? Placing it here affects the profile at the data model source which would likely cause the same blurb-scrub in any other location it might render, but it might also cause problems in areas which need to access the profile data for other reasons other than rendering, e.g. if a profile gets copied/cloned in memory then this might result in losing the profile data altogether. Updating only PhabricatoPeopleProfileController to call cleanupProfile() instead of within PhabricatorUser would only scrub it at the time it's being rendered (to the profile page at least).

Real quick before landing -- should this change be made here in PhabricatorUser or would it be sufficient in PhabricatorPeopleProfileController? Placing it here affects the profile at the data model source which would likely cause the same blurb-scrub in any other location it might render, but it might also cause problems in areas which need to access the profile data for other reasons other than rendering, e.g. if a profile gets copied/cloned in memory then this might result in losing the profile data altogether. Updating only PhabricatoPeopleProfileController to call cleanupProfile() instead of within PhabricatorUser would only scrub it at the time it's being rendered (to the profile page at least).

In D25035#1051, @speck wrote:

I'm having trouble landing this, I keep getting 403 errors. I suspect it's a local configuration issue, though...

All that should be required to land is being in Blessed Committers I think, which you are a member of

Address code review comments

In T15080#1970, @speck wrote:

Unfortunately this type of issue is in an area that's beyond my network/configuration experience. Is CloudFlare our NS provider?

I've only looked at the new auth frameworks briefly (WebAuthn, is there another standard too?). My basic understanding is that the browser provides the client with its own certificate which HTTP requests are able to include with it, as a means of providing authentication for the user. This seems like a reasonable thing to allow though I'd also be interested in learning more about the tech in general.

Unfortunately this type of issue is in an area that's beyond my network/configuration experience. Is CloudFlare our NS provider?

I'm having trouble landing this, I keep getting 403 errors. I suspect it's a local configuration issue, though...

Thank you for the review, @avivey !

We should definitely focus on implementing WebAuthn, as that allows us to support almost every standard hardware key solution out there.

lgtm.

The upstream discussion is at https://secure.phabricator.com/T8787

Closing this task now, to prevent it from turning into a perpetual task.

The choice to not allow administrators to edit profiles is a strange one... at the very least, we should probably upstream Mukunda's patch.

Another one popped up: https://we.phorge.it/p/seo-auckland/