As development of Phabricator is ceasing, what steps will Wikimedia take to ensure staying operational? There is a community fork called Phorge (overview at we.phorge dot it/T15010), but it is struggling to catch on.
Talk:Phabricator
@Xerus2000 Phabricator is a stable codebase. Which specific issues do you have in mind that could threaten "staying operational"?
For example, PHP 8.1 is not supported: https://secure.phabricator.com/T13588
As per the link, PHP 7.4 is "expected to work", but security support for this version will end in Nov 2022: https://www.php.net/supported-versions.php
AFAIK the underlying servers run on Debian. So I'd check the support plans of Debian (for PHP 7.4 etc) instead.
@AKlapper (WMF) right. Still, in the light of this announcement, I think Wikimedia Foundation should have a plan.
I mean, even if it may be OK to run unsupported software for some time (operationally speaking), I don't think we should wait until Debian LTS support ends to start a discussion on this.
Ah, I see how my last comment might be misinterpreted. We do not use a Debian package for Phabricator. I don't consider Phabricator "unsupported software" - there is a forked upstream project at phorge.it.
Well, in the long run or even midterm it is a problem to have a static software without maintenance.
New challenges might arrive, regarding HTTP or security mechanisms or whatever.
In this case shifting to a maintained fork might become necessary. Anyway, jump over a bar when you are in front of it, not half a mile before.
Good to keep in mind that there is a fork now, thank you for the hint, and when migration becomes necessary it is to be checked which codebase or system should be selected then.
See also phab:T302528, proposing migrating to Phorge once it is ready.
@AKlapper (WMF) @DZahn (WMF) I am not seeing any tasks related to community communications on this?
Hmm, I personally don't believe enough people mind or care about this technical detail in the background to justify communications. (I might be wrong of course.)
Is there a task I missed that described what would change on the user side of things?
If/when we migrate from the upstream "Phabricator" software to its fork upstream "Phorge" successor software as what is running at the address phabricator.wikimedia.org, then we'll get a bunch of upstream software changes which took place in Phorge in the meantime. This is maybe comparable to migrating from MediaWiki 1.38 to 1.40 or something like that. (Writing "maybe" as I have not reviewed changes but I played with Phorge locally for a few weeks and did not spot "huge" changes.) This is my impression; others involved may disagree.
Also (I should have shared this earlier), the main technical epic task about this is at phab:T333885
Migrating from MediaWiki 1.38 to 1.40 is tech news material, so this could be along the same lines. But if the impact on the average, non-technical members of our community were more noticeable, or if there's any action that they would need to take (even if it's something minor like "update your bookmarks",), then I would say we may want to coordinate more closely on that.
There is no action to take. The URL remains the same.
Not sure User:DZahn (WMF) did get my ping, so trying again.
How do you sort search results by date created like described here?
Use the Maniphest Advanced Query/Search and use the order by option
{{Edit protected}}
I'm asking for a markup fix in 'interwiki tip' template added by push-f at the end of the article. Thank you!
@Tacsipacsi: thanks for preparing my template for translation and documenting it :) Do you know how to fix the <translate> tag showing on Phabricator?
I think everything will be fine once the template is marked for translation by a translation admin.
Yes, the solution is marking the page for translation. It could be fixed for the time being using different hacks, but I decided not to implement them, and simply wait for a translation admin to mark the page for translation.
@Ameisenigel, could you please help here too and mark the page for translation?
Done
The page says: There is a weekly window for updates and other maintenance tasks on Wednesdays at 5:00PM Pacific (Thursday Midnight, 0:00 UTC)… while Phabricator/Maintenance is a bit more precise: A weekly maintenance allowance is integrated into the deployment schedule for Thursdays 00:00 UTC - 01:00 UTC (Wednesdays 05:00 PM PST - 06:00 PM PST). The problem is that PST=UTC-8 (not -7 !) and PDT=UTC-7 – see en:Pacific Time Zone. I think UTC should be used as the primary time on both pages.
Is the time tied to UTC? Tying to 5:00 PM Pacific (which is sometimes PST, sometimes PDT) and thus having a varying UTC time seems more likely for me, since sysadmins’ work schedule is based on local time, not UTC.
Yes, it's connected to the local time on the West Coast of the United States.
What does "Wikimedia and related software" mean? Shouldn't it be "MediaWiki and related software"?
Would "project management in Wikimedia and of related software" be clearer?
Not really. For me it sounds as if Phabricator were Wikimedia-specific software, designed to use only in Wikimedia projects. Perhaps simple "It is used for tracking issues and project management" would be better. Or "It is used by Wikimedia Foundation for tracking issues and project management".
It is not only used by the "Wikimedia Foundation" but can be used by anyone working on software and software-related Wikimedia projects. The Wikimedia instance of Phabricator is for Wikimedia projects.
I don't get it. As far as I understand Phabricator (just like MediaWiki) may be used by anyone for whatever purpose/project they want. That's why "Wikimedia" used in the sentence is confusing (at least to me).
The Phabricator software itself can be used by anyone and be installed by anyone. That one installation of the Phabricator software which is located at phabricator.wikimedia.org and for the Wikimedia movement is to be used for Wikimedia movement related purposes.
Wikimedia does not "produce" Phabricator. Wikimedia does "produce" MediaWiki.
Maybe it's clearer if you replaced "It is used..." with "The instance located at phabricator.wikimedia.org is used..."? That page is specifically about our instance of Phabricator, because this is MediaWiki.org (and not e.g. a Wikipedia article). But I see how that's all very implicit and a bit confusing...
@AKlapper (WMF) Revision Phabricator being similar to GitHub is an important comparison to make for people first trying to understand Phabricator's role in Wikimedia. Code related to Wikimedia is also usually stored on Gerrit 99% of the time. I can simply add "typically" if you're so keen on it. I personally was confused where code was stored and what Phabricator really was when I first got into Wikimedia development a few months ago. This information would have helped myself and I hope it can help others.
Hi, Phabricator is not very similar to GitHub, apart from maybe also being a software forge. GitHub offers code review, our Phabricator instance does not (except for a small set of projects, and we do want to get rid off that). We mostly use Phab for task tracking; GitHub does a lot more.
Code related to Wikimedia is not "usually stored on Gerrit 99% of the time", not at all - we have a lot of stuff on GitHub instead of Gerrit. See also Developer Advocacy/Metrics#Technical Contributors Map
I can very much understand the confusion where code is stored, because it's simply a mess. That's why New Developers intentionally lists several code hosting locations.
> We mostly use Phab for task tracking; GitHub does a lot more.
Okay, and I clarified that in my edit...
That means to me it's not similar...
How do you not see it's similar. It has issues just like Phabricator. I'd say the #1 used feature of GitHub by communities are issues and that's the case for Phabricator and Wikimedia. It helps new contributors understand that we don't use GitHub and instead use Phabricator only for issues.
No, the #1 feature of GitHub is storing source code. I don’t have statistics, but I’m pretty sure there are far more repositories without any issues than dummy repositories that contain no real code and are used only for issues. Issues can even be turned off, which is not the case for code storage or pull requests.
Totally agreed with @AKlapper (WMF) and @Tacsipacsi; making a comparison to GitHub is extremely unhelpful and will mostly confuse. If you have to compare it to closed-source software people have seen elsewhere, describe it as JIRA or Trello.
@Johan (WMF) has been thinking about priority levels in Phab this week, and it made me wonder whether we could solve some of the problems by changing the words used in the software. Looking at Phabricator/Project management#Priority levels, here's what I think would be clearer:
| Current | Proposed |
|---|---|
| Needs triage | Not rated |
| Unbreak now | Blocks weekly deployment |
| High | I will do this soon |
| Medium | I will do this |
| Low | I will do this eventually |
| Lowest | Needs volunteer |
I think that labeling these in terms of what "I will do" will have the effect of discouraging people from setting priorities when their goal is for "somebody else" to do it.
This post was hidden by AKlapper (WMF) (history)
Thanks for sharing this!
I think the underlying problem is the lack of a movement-wide shared understanding of the term "priority". I interpret "priority" as a mix of mostly "urgency" but to some extent also "risk" and "implementation complexity"/"do the benefits outweigh the costs".
First-person phrasing could be confusing if no assignee is set. Who would be "I"? The engineering manager sorting out a team's priorities? I might be less willing to set priorities at all if it implies that I myself commit to doing something when prioritizing tasks on my team's workboard when I personally might not be able to work on a task due to lack of expertise and skills.
Regarding "Needs volunteer", see phab:T78617.
This might also relate to Bug management/Development prioritization.
Should there be a priority set, if nobody's assigned to/working on it? A team/group could agree to set priorities for each other, but I think that discouraging people from setting priorities when they're not doing the work is probably the right thing. If you're not going to do the work (or have permission from the person who is most likely to do the work), then you probably shouldn't set the priority.
Probably there should be a priority set in an ideal world, otherwise you could not organize/sort larger backlogs. This might be also a reason why Kanban got popular but that's only my interpretation (like having higher priority tasks in the current sprint, and medium priority resembling the next sprint, in a very simplified way).
So in most cases the priority should be low but that's not the reality.
The problem is developing shared understanding and definitions (plus as a limitation in Phab, tasks have one priority field but can have several project tags, and one team might think that a task is more urgent than the other team).
Generally, issue tracking systems have very straight-forward priority settings. Either "Lowest/Low/Medium/High" or "P1, P2, P3, P4" or something else similarly short. The *use* and *interpretation* of those straight-forward names are made by individual teams as their needs require. Putting English sentences/phrases in place of those simple words 1) makes translation more difficult and 2) presupposes how all teams interpret the values, which isn't always the same (rarely is!).
Various teams have documented how they interpret the priority levels with such statements as "UBN!s will be triaged and fixed within 3 days" or similar so discovering how they use (or don't use!) priorities is one option (but not *easily* discoverable, certainly).
I wonder whether it would be possible to make the field uneditable by people who shouldn't be changing it. The main problem isn't teams with different ideas of what "medium" priority means (or even whether it means anything; Editing is not setting priorities at all these days). IMO the main problem is non-devs thinking that if they change that field, then it will have the practical effect of changing when the work gets done.
Interesting... is this a common problem that you experience? My impression is not that many folks expect setting the priority field to influence when something gets worked on, expect for Phab newcomers. But my impression is limited as I do not follow each and every task (despite some contrary rumors out there).
Restricting Priority field setting was originally brought up in phab:T819 (and maybe phab:T1178 for those teams rather relying on workboard columns than the Priority field). Historically there once was a "Can Prioritze" setting (see phab:T583), this is not the case anymore and has been replaced by the "Default Edit Policy". So if this was explicitly wanted it would require some custom code changes and their maintenance.
On a related note, Phab nowadays offers Forms (both for creating a task and separately for editing a task) which allow hiding or locking fields (see e.g. phab:T128540); we may want to increase the use of the Forms workflow to also encourage setting task subtypes (bug report vs feature request) in phab:T253744.
> I do not follow each and every task (despite some contrary rumors out there).
Just so you know, I reject this scurrilous rumor. ;-)
The main problem is misunderstandings by Phab newcomers, and the problem is less practical (if I'm doing the work myself, then presumably I know what it's real priority level is) and more about the gap between expectations ("if I type something here, they'll fix this bug now!") and reality (there is usually very little that any non-dev individual can do to affect the speed at which a given bug is addressed), which results in people feeling hurt and angry. It is mostly a "social" problem. If it were possible to "semi-protect" the field, or if the contents of the field were much clearer, then we'd probably have fewer people being sad and angry about Phab.
I wonder if this is really about the "Priority" of tasks in Phab and not about communication in general: If I write on an on-wiki village pump for the first time about a tech problem, wouldn't I have the same "if I type something here, they'll fix this bug now!" expectation as in Phab?
How would "semi-protecting" the field solve a problem? (Unrealistic thought: Wouldn't completely hiding the Priority field everywhere for 'non-developers' only make more sense then?)
Generally speaking, I'd love people to read docs to understand things: There isn't a large pool of developers to immediately look into things; anyone can report anything but not everyone can fix everything. There are also guidelines how to create good Phab tickets which are linked from the ticket creation form; I'd dare to say the majority of "Phab newcomers" ignores them (plus some not so newcomers too, despite my repeated requests). Sadness and anger sometimes, indeed... :-/ Phab tries to cover both "File a technical bug report as a user in a system which is not a black box like with most other software producing places" and "Plan your work as a developer in a public system" and while that's a open source transparency ideal, these two things maybe collide.
I don't think that posting on wiki has the same effect, because you can see that it's a discussion forum. You would probably hope that your report will kick off a chain of events that leads to your desired change being made, but you aren't likely to think that what you type (beyond the natural results of the facts) would directly change how quickly the problem is addressed. That is, if you post on wiki saying "This is broken, please help", you expect the same initial results as if you post "This is broken" or "This is broken and very important".
If we could "semi-protect" the priority field, people would see that they can't change the priority (directly). They can't change the words on the page and they can't change the reality. The appearance and the reality match. Looking at it from a design-ish perspective, if I can't change the reality, why should I be able to change the appearance? Why would someone bother installing an accelerator pedal (or a brake pedal) for passengers in a car, if the pedal doesn't have any effect on how fast the car is moving?
We lose transparency if we hide the information. My point is that the current system is also not transparent: the system falsely tells users that they can change the priority, even if they can't affect it at all.
Please use Talk:Phabricator/Help for any questions or discussions about Phabricator, instead of this page.
In this document, the phrase Phabricator is often used. Perhaps most of them are used as abbreviations for Wikimedia Phabricator. But Wikimedia Phabricator and m:Phabricator are different and it is difficult to distinct for the first-time readers. In addition, I guess this document explains mostly Wikimedia Phabricator rather than Phabricator , so it is inappropriate to name the document Phabricator. (It should be renamed.)
--HaussmannSaintLazare (talk) 05:02, 5 April 2020 (UTC)
I don't see how Wikimedia Phabricator and m:Phabricator are about different things. Please elaborate. It should not be renamed, as mediawiki.org is a Wikimedia website. Hence it is about technical stuff used by Wikimedia. mediawiki.org is not Wikipedia where an article about Phabricator would be about the general software, not about the instance of that software used by Wikimedia.
Hello AKlapper (WMF) !!!
Sorry, it is a mistake that I wrote
But Wikimedia Phabricator and m:Phabricator are different and it is difficult to distinct for the first-time readers.
I was going to write
But Wikimedia Phabricator and w:Phabricator are different and it is difficult to distinct for the first-time readers.
So, please read my claim again with the above corrections incorporated.
Thank you !!!
--HaussmannSaintLazare (talk) 14:37, 5 April 2020 (UTC)
No, Wikipedia is not mediawiki.org. Hence that is intended and will not change.
https://www.mediawiki.org/wiki/Gerrit is not https://en.wikipedia.org/wiki/Gerrit_(software) either, plus dozens of other examples. If people don't understand the scope of a website, so it be.
Hello AKlapper (WMF) !!!
The gist of my opinion doesn't seem to be conveyed to you. So I will write my opinion changing expression.
My opinion is as follows.
It is a dialect using Phabricator as Wikimedia Phabricator. And in mediawiki.org such dialect should not be used.
Aside from your pros and cons, have you understood the point of my opinion ?
Thank you !!! --HaussmannSaintLazare (talk) 22:12, 6 April 2020 (UTC)
I have understood the point of your opinion. And I do not agree with you, for reasons I already explained in this disussion.
We have. We disagree.
Hello AKlapper (WMF) and Jdforrester (WMF) !!!
Do you mean that m:Phabricator is a document describing w:Phabricator and it does not describe about Wikimedia Phabricator at all ? If so, where is the document in https://www.mediawiki.org/ which describe about the role of Wikimedia Phabricator in MediaWiki development and maintenance work which I want to know ?
Thank you !!!
--HaussmannSaintLazare (talk) 15:42, 7 April 2020 (UTC)
Hi, first question: No. Second question: See Phabricator (which is the page on which you are asking your question.)
There is software out there in this world. If it's relevant, it might have a Wikipedia article.
Some of this software is also used by Wikimedia. For that case, it might have an article on mediawiki.org or meta.wikimedia.org or wikitech.wikimedia.org (depending on scope within Wikimedia).
Hello AKlapper (WMF) !!!
I focus on activities on Japanese Wikipedia, so I have not noticed your response.
AKlapper (WMF) wrote that the question about the role of Wikimedia Phabricator should be written here, so I will write my question.
Before that, I briefly describe how I got here.
One of my main activities is translating articles from other languages into Japanese Wikipedia using content translation.
And I have made several bug reports on Talk:Content translation (because content translations often cause errors.)
I doubted that Talk: Content translation can be a WOP (write only page), as the response to the bug report was unpleasant.
Then, after a question and answer on Talk:Content translation, I learned about the existence of Wikimedia Phabricator.
Well, what I want to know is what is the role of Wikimedia Phabricator in the development and maintenance of MediaWiki.
More specifically, what is Wikimedia Phabricator's responsibility for content translation bug remedy?
I'm guessing from the information I've obtained so far:
- . The actual work of MediaWiki development and maintenance is done by engineers who are members of Wikimedia Phabricator.
- . Wikimedia Phabricator members, like Wikipedia members, are mostly free volunteers.
- . It is up to each member to decide what kind of project each member will participate in.
- . As a tendency for engineers, They are more interested in new development than maintenance work.
- . That is the reason why content translation debugging does not proceed.
I would like to ask whether the above assumptions are correct or not.
Thank you.
PS. I got a Wikimedia Phabricator account by mistake. Though I am interested in program development, unfortunately I only have basic knowledge of VB.
--HaussmannSaintLazare (talk) 02:52, 20 April 2020 (UTC)
@HaussmannSaintLazare See Phabricator/Help for the role of Wikimedia Phabricator in the development and maintenance of MediaWiki. It links to https://commons.wikimedia.org/wiki/File:Introduction-to-Phabricator-WikiCon-2016.pdf.
Extension:ContentTranslation has a section called "Issues" in the infobox.
I would not agree with your bullet point 4 and bullet point 5; see Bug management/Development prioritization. :)
Hello AKlapper (WMF) !!!
Thank you for answering my question in good faith.
I'm not suspicious that you've written you can't agree with 4.5, Because 1,2,3 of the other day's messages are speculations about facts, and 4,5 are not.
However, your sense is still that of a technician, unlike a general user like me.
MediaWiki is the infrastructure of the Wikipedia system including us users.
Users want infrastructure to be stable and functional.
I will write a parable from here.
The current state of MediaWiki content translation is like this;
When I was running on a newly opened highway, it suddenly collapsed and the car fell down.
In this state, it would be natural for the user to get angry if technicians start to create a new highway without solving the cause of accident.
Thank you !!!
--HaussmannSaintLazare (talk) 10:18, 23 April 2020 (UTC)
@HaussmannSaintLazare That parable does not sound like a good fit, as no cars fall down in Wikimedia software and as many many cars have no problems at all. :) If you run into specific (!) bugs with clear (!) steps to reproduce, feel free to follow How to report a bug. And if you are aware of any piece of software which is completely free of bugs and has unlimited developer (wo)manpower to always fix everything and beyond, please let me know. Thanks.
(This message is a Postscript of 10:18, 23 April 2020 (UTC). I will reply above message (when you wrote this ?) after.) By the way, do AKlapper (WMF) know that some account users were blocked due to using content translation in Japanese Wikipedia?
I think these blocks are related to the bad reputation of content translation among some Japanese Wikipedia users. The bad reputation of content translation is probably due to the lack of effort to keep track of each Wikipedia request before development. Alternatively, AKlapper (WMF) may not be involved in content translation at all. However, since you are involved in some form of development, you should be aware of what kind of results your products produce, and be careful about what kind of results will be hapten before starting development. I use content translation because I think that it is not a bad tool if it works properly. But because of the above circumstances, I am feeling a little scared to use it.
--HaussmannSaintLazare (talk) 16:32, 23 April 2020 (UTC)
@HaussmannSaintLazare It could be helpful if you made less assumptions. If you got to https://ja.wikipedia.org/wiki/特別:個人設定mw-prefsection-betafeatures you can see that Content Translation is listed as a Beta Feature. See https://en.wikipedia.org/wiki/Software_release_life_cycle#Beta for the meaning of "Beta": Beta software has bugs by definition, so your expectations surprise me. If you don't want to use beta software, then don't enable beta software. I already pointed out how you could report specific bugs if you want to help in a constructive way and allow others (whoever is interested in that) to potentially investigate bugs.
For questions about users on Japanese Wikipedia, you'll have to ask on Japanese Wikipedia. Thanks!
...and all this now has nothing to do with Phabricator while we are on a page to talk about Phabricator, so you might stick to all the given information. Thanks :)
I accidentally entered a wrong email address at the registration.
I post here because Talk:Phabricator/Help is protected and I can't post.
Sure! Done.
Thank you
There are no older topics