Yeah feel free to review D25301

I still like this. Why is this not going forward? 😄

(I have not tried this patch but I checked with ls -la the mess in my .cache to understand best practices from other software)

• we have an approval from a core contributor
• we tested by at lest 2 persons in real-world
• we tested also in my production for 7 months, using this intensively, without any nuclear implosion
• nobody cares, really, nobody uses Milestones, nobody knows what a Milestone is, people also don't like Workboards, Workboards are evil persons for much core contributors, so we will never receive more feedback here automagically, if we have not received these in 7 months
• since this change is online since the 11st of February (!) :D and since I waited 2 weeks to be kind after approval, ...

Should I go ahead and submit a different patch? Or could I somehow contribute the edit to this patch?

So would the latter option mean doing $html_details = array($head, $more, implode(' ', $exceptions)); here? I kind of find this approach cleaner than appending a space to each item in the $exceptions array.

In D25419#12602, @avivey wrote:

The value of moreInfo here is a list (array) of 3 things, (https://we.phorge.it/source/phorge/browse/master/src/applications/policy/filter/PhabricatorPolicyFilter.php;4f845d8f8c77$702) - $head, $more and $exceptions, and I'm guessing from context that the appendList() creates one <ul> for the list and one <li> for each item in the list - so $exceptions at this point is a single thing.

I don't think we have a specific task for "general UI text improvements" - there's the UX project, but "improve UX" is an ongoing process, so I don't think a single parent task is a good match.

Interestingly: https://secure.phabricator.com/T10574 argues for removal of the additional data from edges.

... whereas the $html_details is constructed as merely array($head, $more, $exceptions); ...

For others reading this thread: there's some discussion going on in the thread of the patch linked above, D25419.

Note: the <ins> tag is typically rendered as underlined text, so this would be very similar to the <u> formatting that is produced with __foobar__ → foobar. In fact, it might be worth repurposing that rule to produce <ins> instead, since ~~foobar~~ actually creates a semantic <del> tag rather than the presentational equivalent <s> (strikethrough) tag.

Ugh. I added this to the UX project but forgot to remove the test content from the comment box, so my changes ended up coupled with a comment that said "- List Item". I tried to delete the comment but now it looks weird like some sort of redacted content :( anway, though I'd leave the note here in case anyone is confused with the deleted comment.

It's also misleading that the text box is multiline (at least in desktop) which suggests that line breaks are expected, but pressing Enter instead sends the message. I was caught off-guard by this at least once. So perhaps the text entry box should be made single-line by default (as already happens if the screen is narrow enough) and expand as needed if line breaks are added.

@valerio.bozzolan I actually think the right place to look at the usage of getSpecialRules() might be here: https://we.phorge.it/source/phorge/browse/master/src/applications/policy/filter/PhabricatorPolicyFilter.php;4f845d8f8c77$693-719

By the way, is there a task or project about UI text improvements that this task could be made part of? I am looking e.g. at the button in this very comment box saying "Set Sail for Adventure", which, while amusing, is also prone to cause confusion.

How about something like "Endorse"? That might remove the connotations of speaking for the project position that something like "approve" or "accept" may imply.

In T15640#13668, @valerio.bozzolan wrote:

Are you aware of any non-git repository in Wikimedia?

Makes sense; let's close for now. (I need to get used to Conduit throwing exceptions into our server log for random broken input. I do not like that Conduit behavior.)

I'm generally scared by strlen() things since it means it was probably relying on implicit cast-to-string.

I'm trying to imagine a title that also involves the UX in general about accepting revisions, since it's also about the "Accept Revision" button, but my brain is not helping me right now in this

Honestly, I don't know why we have old commits improperly filled, you can maybe play with svnadmin command on a dummy repo as described here : Change author of SVN commit

Tested locally, works as advertised.

No further changes requested in 13 days, so am going to land this diff.

I was trying to test this, but I don't know how to do a Subversion commit without a committer name 🤔

PhabricatorFileAttachmentQuery seems to eagerly load the object relation, however since the DestructionEngine extensions run after the object is already deleted, this fails and nothing is returned in the query. Changed to LiskDAO loadAllWhere, which also seems to use less queries in general (due to not eagerly loading), so changed the query in PhabricatorFile as well. Changed mpull to foreach per suggestion.

Decreasing just a bit the priority since we are a bit confused about how to proceed but feel free to change

It could also be some bots sending you fuzzy input. Consider to mark as invalid, until a real human being elevates this as a problem affecting some workflows.

Note that the upstream solution from Phabricator does not fix your problem, since

Are you aware of any non-git repository in Wikimedia?

Kindly marking as "request changes" only to indicate "waiting for author feedback"

Commit fixup/update author details

Organised attachment deletion from the file side into the File object and deletion from the object side into the destruction engine extension. Also updated the SQL patch date in the file name.

Without a reproduction, this is speculative.

Why would a branch name be an integer and not a string?

Looks like this created a regression: T15639: Exception: Value passed to "phutil_string_cast()" is an array in PhabricatorApplicationSearchEngine.php

Fixed my dirty tree, sorry