Maybe this is a clue?

In T15653#13929, @valerio.bozzolan wrote:

Yeah so we are all for "let's just append as default and maybe think about something more for the future, if they ask"

What if it were possible to intentionally remove a tag by passing the tag prepended with - to signify removal? like ?tags=-ABCDE to remove a tag but otherwise the behavior would be to just append. I realize this doesn't have the same compatibility advantages but it does offer slightly more flexibility for use in ad-hoc workflows.

In D25066#8893, @valerio.bozzolan wrote:

Hi @20after4 :) Can I ask you if this could be useful in Wikimedia? I think yep

I like it but I haven't tested locally.

In T15096#11546, @avivey wrote:

Interesting.... Herald could probably start the flow, but there's still more parts needed (update vs create revision, extract summary and test plan)

I suspect there's also a problem of motivation: These things are lots of work, and the people who are capable of performing them - people who are comfortable with working with these tools - will not personally benefit from this stuff. The people who would benefit the most are people who are not involved in the project at all...

Cool extension! We still need to build a proper extension ecosystem for Phorge. Maybe we could start with a wiki page linking to known extensions, then you'll have a place to share your extension, should you decide to do so.

Maybe we should hide profile details for newly registered users as well? Requiring approval would reduce the value that spammers derive from registering accounts. At least it would raise the amount of effort required of the spammers but unfortunately would also raise the effort required of us to monitor / approve accounts . and we would need to define what the user is required to do to prove themselves.

This is a feature that was invaluable on wikimedia's use of phabricator, however, proliferation of a lot of forms can be troublesome / difficult to manage. Ideally the forms system could use some improvements to make things more manageable.

More prior art: https://zuul-ci.org/docs/zuul/latest/gating.html#cross-project-testing

This is a nice contribution and definitely would be a valuable addition to the docs, IMO.

fwiw the phabricator-ava project also has the ability to roll back all changes by a user, however, it won't touch tasks which have been subsequently edited by a different user so the automated tool must be used before attempting to clean up manually or the automation fails.

In T15364#8952, @avivey wrote:

"tooling for chains of diffs" might need its own topic, with a design of the what the whole thing should look like in an ideal world, and how to get to it.
Even if not all of the stuff fits nicely into Phorge, there's probably a lot that can work, and some conduit methods can be added to implement the rest.

Breaking this out from the discussion at T15364: arc land complaints summary by FreeBSD community

FWIW I think the test plan is configurable (that requirement can be disabled in phabricator's config server side which should remove it from commit messages in arc)

Relevant links:

I might be willing to take a stab at this but not sure when I'll have the time.

Phabricator's codebase is mostly high quality and fairly easy to jump into but I probably wouldn't recommend it for someone new to PHP :D

@ton welcome, glad to have your input here.

FWIW even in the case the milestones are strictly ordered, it's incredibly inconvenient to sort out a situation where you need to add one to the middle of the list - forcing the user to rename a bunch of them to get things straightened out.

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.

In T15048#2234, @eax wrote:

IMHO if we are to do this it should be similar to "comment reactions" from github. Useful for e.g., +1 -1 but shouldn't generate visible transactions on the rest of the page.

To me 2 seems like the safest / easiest solution, even if it is a bit limited.

This looks good to me. It seems like I may have actually ran into this before and just didn't manage to upstream the fix from Wikimedia's fork.

Well that didn't work: T15114: Can I create tasks?

I'll remove myself from trusted contributors just to test.

The form ( https://we.phorge.it/transactions/editengine/maniphest.task/edit/2/ ) needed a security policy. I think that should fix the problem?

https://secure.phabricator.com/book/phabricator/article/custom_fields/ custom fields allow you to set the required property in configuration. I'm not sure if you can use this to override a default built-in field but you could possibly replace the built in field with a custom field with same/similar name and type: users.

In T15096#2233, @speck wrote:

Thank you for these write-ups, I'll need more time to review however I noticed Evan recently started a task in the upstream where it looks like he's investigating compiling PHP to a library for use with a custom native entrypoint which would allow distributing arcanist as a single binary (he estimates ~10mb in size).
https://secure.phabricator.com/T13675

This seems sensible to me, FWIW

@micax: Good points and it's helpful to hear another perspective on this. From my past experience using Phabricator on a corporate team I definitely think that arcanist helped keep everyone's workflow consistent and simple.

Fix line length

celerity map

Does anyone else feel that this is not a good idea? Seems like the consensus here is that it's at least acceptable if not desirable to have.

I did a bit of digging through the source code and it looks like tokens are implemented in an incredibly generic way, such that it wouldn't be at all difficult to add tokens to comments. I think the hardest part will be integrating it with the UI.

In T15090#2141, @avivey wrote:

In T15090#2123, @Matthew wrote:

@avivey Would it make sense to add a public announcement to Diviner or Phiction? Or perhaps we use Phame for this use case (Create a "Security Incidents" blog)? I always think of a task as an actionable item, whereas we would want this to exist forever.

Yes, probably. "Announcements"-style thing

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

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.

• 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"