Here's another one that I think deserves to be upstreamed: https://phabricator.wikimedia.org/T230787 adds context and search term highlights to fulltext search results. Currently Phorge and upstream Phabricator only show matching document titles with highlights on keywords in the title but not the body.
The efficiency of my solution is questionable, however, it's working well enough for Wikimedia's use of the feature.

there is a presentation from eric brechner, who was in microsofts xbox development, about kanban. he does it on whiteboard, extremely sinple:
https://www.youtube.com/watch?v=CD0y-aU1sXo

From a product POV, I agree with @valerio.bozzolan - there is (sometimes) some information on commits that would be nice to index in a search engine - comments, mostly.

Valerio: Uhm, I'm sorry, I had not seen your comment here before I landed the patch (as I had checked my Differential page instead of my notifications).

This is something that may be not appreciated by some people.

One of my favourite updates in my workplace was to store counts of feature usage per month in a table. Move forward 3 years, and whenever we need to update some code in a feature, we check for it in the table, and if it's not been used in 3 years we just scrap the feature.

I triage this to Wishlist since it's indeed useful to some people but it's somehow still controversial. In order to attract more eyes, adding also Discussion Needed.

Thanks but I don't know where that typo is, so, feel free to fix

See e.g. https://www.law.cornell.edu/wex/release why to "license under" instead of "release in"

I don't remember but that was an attempt to do not release Passphrase credentials as CC BY-SA 4.0 :D :D

Public contents are released in Creative Commons Attribution-ShareAlike 4.0.

Updated to reflect some tips from comments. Also added some "Pro / Cons"

+1 for CC BY-SA 4.0 International for content (text, images, etc) and Apache 2.0 for code.

Content is not in something, rather it's licensed under.

Thanks @aklapper, feel free to edit the Task description according to your proposal.

Public contents are in Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA) and Apache 2.0 unless otherwise noted.

In T15322#11590, @valerio.bozzolan wrote:

This would also help Wikimedia volunteers to upload screenshots of Phorge to Wikimedia Commons, avoiding annoying deletion procedures for the lack of the license in the very same page etc.

Would taking care of the depreciations bump the minimum PHP version required to run Phorge?

Not in itself, but we do plan to bump the minimum to 7.1 (in T15047).

Would taking care of the depreciations bump the minimum PHP version required to run Phorge?
looks good to me otherwise

@ncoker See T15586 instead

thank you @ncoker, but:

1. This is not a task to discuss specific errors when trying to run on php 8, and
2. We don't expect arcanist to work on php 8 yet

Maybe also something for this topic!
We update php yesterday on our WSL2 (Ubuntu 22.04) clients to 8.1.22 and pulled the latest arcanist from git after the commit
Now we facing this problem on starting arcanist:

D25386 and D25387 provide the big "do not crash on deprecation warning", and are probably enough to declare "experimental support for php 8.2" on their own.

I was thinking "out out", but only visible to admins - and then, only as a yellow notice at the top of the page:

This is a good plan. Would this be opt-in, e.g. this Phorge instance would be the main one with this on but other installs wouldn’t see this by default?

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

(Implementation notice: in both phorge and arc, this is handled in PhutilErrorHandler::handleError(), and the check is simply $num === E_DEPRECATED), and maybe E_USER_DEPRECATED.

+1

I agree that Phorge should not fall over because of a deprecation warning.

I've extracted T15535: Using Differential with plain Git, without requiring Arc for the git-push-for-revision.

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