In T15043#1256, @speck wrote:

Making this an object rule is not possible as it has to be a Maniphest Task rule, which do not support object rules.
My main reason to explore this, is that without column types, we can only create rules like this "If task status changes to complete, then move task into column DONE in Project A.". Which means we have to create this rule for every project. In the rule builder UI we would also have to load a list of all project boards and their columns, which could be quite a few. The herald rule doesn't know with which project a task will be connected.

Ah okay - I was thinking this would be a Project rule rather than Maniphest, which would allow it to determine what possible columns can be used in the rule/action definitions.

In T15002#1224, @TitanNano wrote:

I just wanted to note that Phrequent is an integral part in my company, even though it's a prototype. We heavily rely on time tracking.

In T15044#1193, @speck wrote:

Functionally I think this makes sense, though from a higher perspective the concept of "multiple authors on a revision" might need to be discussed and fleshed out.

Technically this workflow can be supported today as arcanist will allow you to make updates to a diff that was originated/authored by someone else however in my experience this tends to be fraught with issues [...]

In T15035#1188, @speck wrote:

@TitanNano with the matrix bridge up could you provide instructions on how to connect to that? I setup the Element client on my machine but I'm not sure how to get on that phorge channel.

I would support using approach number 3 and actually consider moving the triggers into Herald in the long run. Triggers are only dispatched from Javascript when moving the items on the board, but moving them within a task using the "Add action..." dropdown does not trigger them.

In D25019#617, @speck wrote:

This looks good to me.

I'm curious how often these scripts are used. I haven't used them for any of the installs I set up but I largely wasn't aware that they existed.

I'd suggest starting of the starmap by shedding some/most of the applications that were not part of the core of Phabricator or have been in the Prototype phase for a long time, allowing the project to regain focus and improve on the things that make Phorge unique. This would provide a number of advantages:

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!