I don't know if that is part of this task, but the global typeahead search should hide all disabled users, wikis and repos, shouldn't it? This is nothing you want as a fast suggestion...
- Queries
- All Stories
- Search
- Advanced Search
- Transactions
- Transaction Logs
Advanced Search
Feb 12 2024
Well, my idea would be:
Feb 11 2024
Feb 6 2024
When I was at Wikimedia I remember a lot of issues from search robots endlessly indexing dynamic pages.
Feb 5 2024
In case of what?
OK. Then we can add a Task about how to easily configure robot changes without forking, in case.
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.
Feb 1 2024
So apparently the ferret search engine doesn't really have any sort of dynamic ranking. The ranking is entirely based on how many ngrams match the query...with one singular exception - all user results are boosted above everything else.
I'll try to figure out a architecturally-appropriate way to do this. The users do get grayed out in the typeahead search, just not on the results pages.
Partially related, from the mentioned search it's easy to recognize closed Tasks, but Users are not greyed out when Disabled.
Jan 28 2024
Jan 22 2024
Jan 20 2024
User content is also content, thus yes.
Jan 19 2024
Good question. Maybe also related to L2.
Is it assumed that using the site will automatically license the user’s content under these, or should there be a line for that?
In T15322#15031, @aklapper wrote:+1 on Content licensed under Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA) unless otherwise noted; code licensed under Apache 2.0 or other open source licenses.
Values given in em units may produce unexpected results...
Jan 18 2024
Yes. I think we should wait for a kind Administrator to implement the first one.
BTW I like the proposed screenshot. So I also agree to: feel free to share the solution 👍
My fix would work with this css class
I did not realize you had a fix. Please share it. :)
In T15715#15174, @aklapper wrote:I guess you could get the result that you're looking for by editing the file webroot/rsrc/css/aphront/typeahead.css and removing the line white-space: nowrap; from the definition of div.jx-typeahead-results a.jx-result. I just don't know which side effects this may have in other places...
Jan 17 2024
I guess you could get the result that you're looking for by editing the file webroot/rsrc/css/aphront/typeahead.css and removing the line white-space: nowrap; from the definition of div.jx-typeahead-results a.jx-result. I just don't know which side effects this may have in other places...
Jan 13 2024
Also for Archived Projects, and maybe some other objects.
I'm not sure if there's a generic way to do this, or if each search-engine needs to be updated manually.
+1 on Content licensed under Creative Commons Attribution-ShareAlike 4.0 (CC-BY-SA) unless otherwise noted; code licensed under Apache 2.0 or other open source licenses.
Jan 10 2024
Completely agree on lowering their ranking as default
Jan 9 2024
Dec 18 2023
Dec 14 2023
Since I can, thanks to that revision, at work I've put this additional CSS rule for extra nonsense scary climax.
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.
Dec 8 2023
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
Dec 7 2023
Dec 6 2023
Nov 20 2023
Nov 19 2023
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.
Nov 18 2023
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).
Nov 17 2023
Nov 16 2023
This is something that may be not appreciated by some people.
Nov 15 2023
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.
Oct 11 2023
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.
Oct 6 2023
Oct 3 2023
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"
Oct 2 2023
+1 for CC BY-SA 4.0 International for content (text, images, etc) and Apache 2.0 for code.
Sep 4 2023
Content is not in something, rather it's licensed under.
Thanks @aklapper, feel free to edit the Task description according to your proposal.
Sep 2 2023
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.
Aug 26 2023
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).
Aug 25 2023
Would taking care of the depreciations bump the minimum PHP version required to run Phorge?
looks good to me otherwise
Aug 15 2023
thank you @ncoker, but:
- This is not a task to discuss specific errors when trying to run on php 8, and
- 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:
Aug 12 2023
Aug 11 2023
Jul 28 2023
Jul 27 2023
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?
Jul 26 2023
Another problem dramatically frequent for newcomers (at least in my office).
Jul 24 2023
(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.
Jul 18 2023
+1
Jul 17 2023
I agree that Phorge should not fall over because of a deprecation warning.
Jul 14 2023
Jul 6 2023
I've extracted T15535: Using Differential with plain Git, without requiring Arc for the git-push-for-revision.