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)

( The CLA → https://secure.phabricator.com/L28 )

If it's urgent, we can apply a strict CLA now (basically copy Phacility), and soften it later, once we've had legal counsel.

Has anyone experimented with using arcanist in a docker container? I see two people have published these on dockerhub:

• https://hub.docker.com/r/nasqueron/arcanist
• https://hub.docker.com/r/adlogix/arcanist

It's all a matter of risks after all. Keeping everything as-is ("all rights reserved") just increases risks for every contributor, including Administrators.

yeah, well, we still can't afford legal advice. If some funded organization is willing to donate some, we'll appreciate it.

At the moment, if somebody makes a comment in the website with a creative snippet, that is "all rights reserved" from that author. Same on Differential, since volatile patches can be somehow considered as out of the repository.

@valerio.bozzolan I think you're confusing this task ("website content") and T15121 (contributor agreement).

Since I am not currently authorized to make changes on other people's code from comments or Differential and I don't want to be vulnerable to copyright trolling.

Interesting.... Herald could probably start the flow, but there's still more parts needed (update vs create revision, extract summary and test plan), and it technically can't delete the branch (it can prevent it from being created, but that shows up as an error in the user-side).
But it should be able to at least trigger the flow and provide a URL for the user to click on.

Could this be solved with a Herald action?

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...

Uhm. Have we any idea about how to unlock this situation?

I think the current actionable steps we can take are:

I posted this in a separate thread, but it is definitely related: https://we.phorge.it/T15524

How would we as phorge upstream use the info? Would it inform development? Be just informational?

How would we as phorge upstream use the info? Would it inform development? Be just informational?

Premising that a CLI script could be not enough, probably better a frontend button so to be able to know if it's mod_php or PHP-fpm etc.

Personally, I'd be willing to manually fill out a survey. I'd heavily oppose anything that phones home in any capacity.
An app/script which generates some report which can be manually copy-pasted sounds reasonable.

Uhm. Maybe we can create a script or a frontend button to auto-answer most of these questions.

For completeness, my arguments against this:

I think the current revision is a good compromise. The current behavior makes no sense from the perspective of modern UX patterns:

I think updating the user script is a good idea if this functionality is needed.

In T15161#4416, @avivey wrote:

I agree with this, but I think we should let this wait for broader discussion - there maybe good counter-arguments.

Then let's decline this ticket to reflect the status.

(I'm against this, but I don't have the time to go into details right now. I suggest a CLI tool (like ./bin/user) to expose this information).

Premising I am trying to make few variations to the current behavior implemented by Evan

Just to clarify as a side note, this will probably not solve the problem of people wanting to reorder their Milestones.

Maybe we can start implementing this just like the way the Show hidden Columns top-right Workboard menu was implemented: so, we add a Show Sub-Projects as a way to use that filter, but not as default.
This can give a margin of creativity to change things without much complaints, and still gives the ability to have a permalink to that situation, and so, allowing to adopt that view as default.

I think I just imagined replacing the (default) query from "tasks tagged with project X" to "tasks tagged with project X or any subproject of X".

In T15231#5924, @valerio.bozzolan wrote:

Apart from my wall of text, having said that a Task cannot stay in multiple Milestones from the same project, so on the Workboard you never see duplicates, this is the current blocking:

a Task can be attached to multiple Sub-Projects

So, probably this simply cannot be done as-is now, without deciding what to do, to avoid duplicate Tasks on the same Workboards, when we will somehow introduce this feature

Apart from my wall of text, having said that a Task cannot stay in multiple Milestones from the same project, so on the Workboard you never see duplicates, this is the current blocking:

To be honest this could create a performance issue in my installation, since I use Sub-Projects as a simple way to collect many Projects that must be grouped but that have different features.

Interesting question.

I don't personally have much insight into the "board" functionality, because I've never used boards in any setup other then as a simple table, and none of the workflows that involve moving small pieces of paper around make sense to me.

I think a tooltip would clear up some of the confusion around the numbers and what they mean. However, I think the issue described here is less about how confusing it is, and more about how the UX expectation is typically centered around count rather than points. For example, which has the denominator, turns the UI red, etc. So, a good idea! I just think it's separate. :)

By "tooltip" do you mean something that activates when hovering with a mouse?

In T15100#5480, @avivey wrote:

@MBinder_WMF - how much of this will be solved if we just add a tooltip to the [ X | Y / Z ] header?

@MBinder_WMF - how much of this will be solved if we just add a tooltip to the [ X | Y / Z ] header?

I think we can remove the Discussion Needed Tag since at the moment we just need to clarify a bit the feature, before being able to discuss it with more people

Ihihih OK my friend

I agree. Having said that I'm not bold enough to propose a "default: open in same tab" since at the moment we have the exact contrary. That is why I proposed this compromise based on the destination.