Another good simple candidate GDPR-friendly:

I'm not familiar with MediaWiki's packages - the model I'm copying is VSCode.
My thought is that in the install manual we'll say "now run ./bin/extensions install phorge-recommended-extensions" (near the ./bin/storage) step, and phorge-recommended-extensions would be the equivalent of "extension pack" hosted on the default Extension Store, which is hosted here.
(VSCode also has "bundled extensions", which I think doesn't work for us because we use "clone the repo" as the primary distribution system).

In T16007#21223, @avivey wrote:

In T16007#21196, @Cigaryno wrote:

In T16007#21194, @avivey wrote:

Ideally, any current Prototype can be either promoted to Core, extracted to its own extension, or removed completely. Each extension/author can have their own policy on contributing.

Already, any new app that would be considered "Prototype" today should just go in its own extension, and we decided to remove a couple.

It depends on who on the wild (including large private companies developing closed-source software) is using prototype applications on Phorge. This should let us know if it should be promoted to core, separated into an extension, or removed completely if no one uses it (like Releeph and Phragments). Or even better, hold a Slowvote for each prototype application's future and possibly have Phorge's customers to vote (maybe notify as much as possible by creating a blog post about the vote to notify those who use the Atom feed).

I'm not sure that "usage" is really the best way to choose between "promote to core" and "extension"; The way I imagine it, in addition to the Core, we'll have a set of "highly recommended extensions" maintained, and a single step to install all of them when setting up a new machine. In that world, any app that can be separated out to an extension will be.
The prototypes can usually be curved out easily, without effecting the rest of the code.

In T16007#21196, @Cigaryno wrote:

In T16007#21194, @avivey wrote:

The "Prototype" concept was a way for Phacility to experiment with things without committing - but we have a different model today.

Really!? Phacility SaaS instances do not allow enabling prototypes and self-hosted Support (from the Support application on admin.phacility.com that was oddly marked as Prototype) likely wasn't even available for prototype applications.

In T16007#21196, @Cigaryno wrote:

It depends on who on the wild (including large private companies developing closed-source software) is using prototype applications on Phorge.

See T15501: Voluntary Usage Survey App basically.

Or even better, hold a Slowvote

Please no popularity contests (with even higher self-selection bias)...

In T16007#21194, @avivey wrote:

My thought on this is that long term, we'll remove the concept of "prototype" completely in favor of Extensions.

Prototypes that need a long way before being promoted to Core are those that should be separated into extensions.

My thought on this is that long term, we'll remove the concept of "prototype" completely in favor of Extensions.
The "Prototype" concept was a way for Phacility to experiment with things without committing - but we have a different model today.

In T16007#21080, @aklapper wrote:

I do not think changes are necessarily needed, because it already says "With rare exceptions".

Bug fixes and security patches are indeed exceptions but not rare exceptions, assuming they fix problems with rough prototypes.

I do not think changes are necessarily needed, because it already says "With rare exceptions".
Regarding the proposal, I do not believe that "prototype applications [...] are often subject to significant changes" either.

I'd be very much in favor and I'd be happy to contribute changes for this. I've added type hints in my local fork to assist in development. Especially for core utility functions like idx and id which otherwise completely hide type information.

Suggested meme for closing: "yesyes"

In T15100#18699, @aklapper wrote:

I'm not skilled enough to look into the bigger picture, however maybe the Edit Column dialog could have a third field apart from Name and Point Limit to also have Task Limit (or Card Limit?). Point Limit and Task Limit then must be mutually exclusive (do not allow to set both for a column, or even...board?), somehow.

(we can probably keep this ticket open, so that we have the 2nd part on the backlog. I'm pretty sure we want it to happen "eventually".)

Feel free to show something early :) That would attract more attention than the Discussion Needed tag I bet

Wrote the code for the first phase :p

Sounds good to me :p

We can also ship this feature in two phases, so, first, adding the option files.maximum-file-size, and then the second one when it's ready or requested lol

Yeah, I agree, though I would then only work on implementing files.maximum-file-size because we don't really care that much about adding exceptions to the rule (as far as I know lol)

Uh, that would be so good. So you can say "When the moon is full".

Sounds reasonable.

I like your option names. I like to specify PHIDs and not numeric IDs so it's more portable against import/exports 👍 Let's add Discussion Needed to attract some +1 or nice suggestions.

There is a significant amount of Phabricator dark matter out there - companies/people using the software, it works well enough, not really easy to know they exist or anything about their usage. I'm sure at least some of them have moved to Phorge. Automattic/wordpress.com have moved to Phorge and I wasn't even aware that they were using Phabricator before that. This is despite the fact that I did a pretty extensive amount of research to identify every company using Phabricator back in ~2019 as part of my work for Wikimedia, with the goal of reaching out and trying to organize an informal Phabricator users group. We had the idea that the various corporate users probably had good reasons to be collaborating and at least talking to each other since most of them were not active in the upstream project. Anyway, that never really panned out, although it did trigger a flurry of interest and some ongoing discussions via email (maybe even one video meeting but I can't remember the details now.)

Abandoning in favor of T15890 and D25774 per previous discussion

I think that is complex because some admins are not well active on their platforms, so as said before it can be underdimensioned

I'm not skilled enough to look into the bigger picture, however maybe the Edit Column dialog could have a third field apart from Name and Point Limit to also have Task Limit (or Card Limit?). Point Limit and Task Limit then must be mutually exclusive (do not allow to set both for a column, or even...board?), somehow.

OK. If you are partially mentioning nonsenses in we.phorge.it itself, you are indeed right.

We might come from different user journeys.
Your users might be aware what the project means, and that the project (and its workboard) is archived, and they do have an initial reason to look at this archived workboard (e.g. default view is not "open tasks" but "all tasks")?
My users clicked an external link to some project tag in something called Phorge, and that project has been archived in the meantime, and that project is set to show the workboard by default, and that is now just empty columns (as the default view of workboards is "open tasks"), and that is confusing and unhelpful.

(Trying to make this task a bit more about the root problem, and less about the proposed solution)

I mean. See this archived Project (archived Milestone), that is linked from our changelogs:

For example, some people then may ask "why my default view was changed?" and they will start manually "rollbacking" this to their desired view (e.g. showing closed tasks, from the Workboard, with a filter "Show all tasks").

Premising that I like the implementation but I think it's not the desired solution.

I think GitHub allows that syntax only in comments 🤔

In T15744#18236, @20after4 wrote:

I was unaware of `#0969DA` syntax from github/gitlab.

I was unaware of #0969DA syntax from github/gitlab. I'm not sure if I like that syntax better than {} but I am generally in favor of using the same syntax as other systems in order to converge towards defacto standardization.

Thanks again @20after4 for the efforts.

In T15096#12185, @valerio.bozzolan wrote:

Another problem dramatically frequent for newcomers (at least in my office).

It's relatively too much easy to start with a similar commit message:
...

At least, please go to GitLab, instead of GitHub, so at least you use Free Software :)

Just some (probably final) thoughts on arcanist and phabricator/phorge. After quite a bit of discussion internally, we are moving on to GitHub with our repositories (which were previously stored in another Git server - not Phabricator). But that move also spells the end for our/my 10+ year long use of Phabricator, because when we move to GitHub, we'll also be ditching Phabricator for code reviews.

It seems to me that this problem can be solved with an additional setting that turns this functionality on or off.

Probably my somewhat 10 cents at a broader level;

We don't create the links to page$line in most places as hrefs, so this shouldn't be an issue.

• Don't exist in Diffusion
• Do exist in Paste
• Don't exist in Differential

If it's that easy

I'm guessing $ is used instead of # because (1) a user-agent might not send the # part to the server, and (2) the natural behavior of # ("scroll to this anchor") isn't what the intended behavior ("highlight these lines and scroll to the first one").

Ah, also adding a smalll meta "noindex" HTML tag on legacy file.php$123 pages and similar ones, would maybe help a little bit.

In T15670#15501, @avivey wrote:

Thinking more, I think we'd like to allow the robots to index latest version of the code - these days the big boys know how to handle that. Stopping them from crawling older versions is still important.

Anyway, I vote to revert the change - commit pages can have discussions in.

If it's that easy, then I'm both impressed and surprised it remained this way for so long. I'm actually not quite sure I understand the reasoning for not using # to begin with.

In T15670#16064, @valerio.bozzolan wrote:

A root problem is that highlighted line number(s) should be a # fragment really, to do not multiply pages exponentially.

Another good simple candidate GDPR-friendly:

In T15670#16064, @valerio.bozzolan wrote:

A root problem is that highlighted line number(s) should be a # fragment really, to do not multiply pages exponentially.

A root problem is that highlighted line number(s) should be a # fragment really, to do not multiply pages exponentially.

In T15728#15768, @valerio.bozzolan wrote:

I tried to understand the situation. Thanks.

In your opinion: on the repo view (with clone buttons) is it really important to link to the other similar "reduced" view (without clone buttons)?