I agree that an additional status is needed for closing when creating a task. Current statuses are not obvious. "Closed, Graduated" is good to fast decision.

I've created R10 PhorgeIt Extension for this, with a little bit of content. I'll load it to the server shortly.

I sincerely thought that "Obsolete" was the good one semantically.

Seems like it is solvable via

While Deploy Keys do not appear to be the tool, I just configured a new Personal Access Token that's tied to the PhorgeIt organization. If there are any issues, please open a new task and assign it to me, I'll take a look.

It's an infra issue, but it's our infra :(

Yeah. Maybe also test plans etc.

What is being referred to as "Public Contents"? Wiki documentation? Diviner documentation? Ponder questions/answers? Other than those I'm not sure that should apply.

Issue on my end, will try to get the Mysql credentials set up for running tests

Ah! That makes sense!

(Unless there's some PHP 8.2 bug in my arc invocation... )

Pretty sure, here's the full --trace output, you can see it's trying to talk to we.phorge.it (also, I see we.phorge.it in my ~/.arcrc)

I say this, since we are receiving Diffs from many other people without issues it seems:

Are you 100% sure that you are communicating with this upstream?

(there used to be a "feature flags" application in Phabricator,

I can no longer reproduce this, so I'm guessing it was something bad in my setup.

I never tested that, but maybe we can create a couple of minimal Herald rules consisting in "Use Herald Rule H22" or similar

I've added H22, but I think at this point we should start writing code for what exactly is allowed/not allowed for these two branches.
It's also kind of annoying that there's no way to use the same rule for both repos.

Yeah sorry, I mis-used Projects since I was not bold enough to mark more appropriately with #Milestones (that we know are a type of Project internally)

OK thanks, so I understand what was the last cleanup: you helped in removing some Projects where was related to Workboard and #Milestones but the last one does not exist.

I removed the tag from some tasks that are about Workboards and not about projects.

Projects isn't archived.

I'm still confused. I noticed that the Projects (archived) was archived since probably it was a sub-project, but why also Projects was emptied? It's a core component of Phorge, and it contained more than 3-4 Tasks inside (so, inside the avivey rule of thumb mentioned above). In this way I just feel like am I bothering you, just for trying to organize a massive work on a community project?

I'm done cleaning up Projects for now.

I'm ok with you creating a new Files tag for the Files app.

Avivey I understand your point of view, but please understand that it's really not feasible to look for "files" in the search engine, since we know in the IT everything is a file. Instead, just allowing people to click on a Tag and see some Tasks that are really related to what most looking is looking for (Files component), it's useful.

@avivey, @valerio.bozzolan this is not a place to discuss Files (archived).

We have a really good text-search system. Just go to maniphest and search for "files", you'll get everything that's related to it.

In T15130#5832, @avivey wrote:

I archived Files (archived) because there was nothing there.

In T15130#5832, @avivey wrote:

I archived Files (archived) because there was nothing there.
If it gets traffic, we can create a relevant tag.

There's no reason to create projects/tag on the off-case that "we might need this some day".

I archived Files (archived) because there was nothing there.
If it gets traffic, we can create a relevant tag.

In T15130#5813, @valerio.bozzolan wrote:

I disagree: I strongly suggest to keep the ability to use Projects as Tags. One problem is Mobile that affects mobile users, but it's not related to a particular area of interest like Diffusion. Also, Files (archived) , I don't agree on archiving it, since having that Tag dramatically simplifies searching for that specific topic on a search engine.

If one topic has multiple tags, is just easier to find it. Not less difficult. It's just a matter of having clear Projects for components) and Projects for topic Tags.

In T15130#5812, @avivey wrote:

For php, eg, having a column for "8.2" under "php 8" is plenty detailed enough.

I disagree: I strongly suggest to keep the ability to use Projects as Tags. One problem is Mobile that affects mobile users, but it's not related to a particular area of interest like Diffusion. Also, Files (archived) , I don't agree on archiving it, since having that Tag dramatically simplifies searching for that specific topic on a search engine.

For php, eg, having a column for "8.2" under "php 8" is plenty detailed enough.

Adding lots of projects makes it harder to find the right project for a given thing.

I'm also the author of the first table here in the Change Log:

In T15130#5798, @avivey wrote:

@Cigaryno Phorge was only part of "organize projects here" task.

@Cigaryno Phorge was only part of "organize projects here" task.

In T15130#5794, @avivey wrote:

ah

For our codebase, it's enough to have a single "8.x" tag. We have several millions lines of code less then wikimedia.

In T15130#5788, @avivey wrote:

@Cigaryno wtf?

For our codebase, it's enough to have a single "8.x" tag. We have several millions lines of code less then wikimedia.

In T15130#5784, @avivey wrote:

I'm starting on some of the top-level redundancies (such as ..., and at least 3 different projects for php 8 support!)

@valerio.bozzolan what?

Just a clarification:

@Cigaryno wtf?

I've killed all the stuff from under Phorge, and I'm starting on some of the top-level redundancies (such as Typeahead and typehead, and at least 3 different projects for php 8 support!)

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.

@20after4 Is it a problem for you if this is just a Diff, instead of a cherry-pick?

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?

@valerio.bozzolan please archive Diffusion Repository Creators.

OK no problem. Thanks for clarifying that

The point in L1 about "decrease the privileges of the Administrators" was about the product, not about this install. It means allowing more things to be diverted from "admin only" to customizable permissions.

I see your point. Having said that reading L1 Phorge Vision Statement I see that we are trying to decrease the privileges of the Administrators so that they are not really Super Administrators. I like that. For that reason, and just because in Phorge it's easy to decentralize permissions (while in any other platform this is a pain), and also because the proposed group Diffusion Repository Creators is editable by both the members and by Administrators themselves and so there is no risk of creating a sub-group of gatekeepers, I think creating this group can be another step in the direction of decentralizing a bit the privileges.

I think we already have too many groups, and not enough demand for new repositories.