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"

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

@MacFan4000 the mediawiki auth is in core afaik. There is some custom stuff for the wikimedia ldap setup but the oauth part was merged upstream ages ago.

Yeah admittedly what I did was just a hack because I didn't want to implement storage and UI for a new "hidden" boolean flag.

On Wikipedia’s phabricator instance I implemented a patch that hides the profile text on disabled accounts which helps (slightly) to disincentivize spammers.

Once the rebranding is complete we can send updated strings to translatewiki so that everything remains in sync.

I didn't know columns could be deleted... I thought they were only ever hidden.

In T15048#1311, @Leon95 wrote:

^^ Awarding a Token to a "... awarded a token." Message would be a weird case. But what about removing this Message completely? (or add the Option to hide them) It bloats the history of some Objects imensely and is not that usefull in my opinion.

In T15043#1246, @TitanNano wrote:

Just having a dropdown here would be enough, I guess?

Indeed.

@TitanNano: One way to store the type, without changing any schema, would be to drop it into the metadata json blob which columns already use for recording which column is the 'default'. Unfortunately that isn't the most convenient thing to query, however, it's not that bad thanks to mysql's json functions.

It wouldn't be too hard to add a type to columns but we'd need a way to set the type from the UI somehow.

I also agree that #3 seems promising. FWIW it's incredibly easy to develop new herald actions and as long as the current herald rules do the thing you want to do then the action would be very straightforward. Maybe the usability would be improved by exposing the rules that affect a board through the workboard UI instead of having them scattered around random and disorganized herald rules in the herald ui?

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:

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.

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.

regarding a monorepo, I'm not sure if there is an advantage to that, I'm fine with individual repos. I currently maintain most of Wikimedia's extensions in a single monorepo but I'd consider splitting them out into individual repos if any one them were candidates for upstreaming.

I'd like to host https://github.com/wikimedia/phabricator-antivandalism here, perhaps under a new name.

I landed this upstream.

@willson556: phorge-devcontainer looks awesome. I'll try it out asap. I may be able to contribute as well, I've got a bit of experience building reusable development environments.

In T15004#100, @speck wrote:

On the topic of increasing community involvement we will also want to produce documentation for setting up development environments as well as the steps to submit changes upstream (like a quality checklist). To make development environments even easier we might want to consider supporting something like a vagrantfile so people can get started with very few steps.

fwiw the old upstream workflow has been very easy to follow as a downstream fork maintainer so I like keeping it mostly unchanged.

Shouldn't we also think about changing the name of arcanist or does it make sense to have a fork with the same name?