Talk:Phabricator

Jump to navigation Jump to search

About this board

Please use Talk:Phabricator/Help for any questions or discussions about Phabricator, instead of this page.


See also related subpages

Previous discussion was archived at Talk:Phabricator/Archive 1 on 2019-01-23.

Rename the priority levels

10
Whatamidoing (WMF) (talkcontribs)

@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 and proposed labels
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.

AKlapper (WMF) (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)

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.

AKlapper (WMF) (talkcontribs)

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).

Greg (WMF) (talkcontribs)

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).

Whatamidoing (WMF) (talkcontribs)

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.

AKlapper (WMF) (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)

> 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.

AKlapper (WMF) (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)

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.

Reply to "Rename the priority levels"
AKlapper (WMF) (talkcontribs)

Please use Talk:Phabricator/Help for any questions or discussions about Phabricator, instead of this page.

Reply to "Use Talk:Phabricator/Help"

Do not abbreviate ''Wikimedia Phabricator'' as ''Phabricator''.

16
Summary by AKlapper (WMF)

No.

HaussmannSaintLazare (talkcontribs)

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)

AKlapper (WMF) (talkcontribs)

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.

HaussmannSaintLazare (talkcontribs)

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)

AKlapper (WMF) (talkcontribs)
HaussmannSaintLazare (talkcontribs)

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)

AKlapper (WMF) (talkcontribs)

I have understood the point of your opinion. And I do not agree with you, for reasons I already explained in this disussion.

Jdforrester (WMF) (talkcontribs)

We have. We disagree.

HaussmannSaintLazare (talkcontribs)

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)

AKlapper (WMF) (talkcontribs)

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).

HaussmannSaintLazare (talkcontribs)

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:

  1. . The actual work of MediaWiki development and maintenance is done by engineers who are members of Wikimedia Phabricator.
  2. . Wikimedia Phabricator members, like Wikipedia members, are mostly free volunteers.
  3. . It is up to each member to decide what kind of project each member will participate in.
  4. . As a tendency for engineers, They are more interested in new development than maintenance work.
  5. . 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)

AKlapper (WMF) (talkcontribs)
HaussmannSaintLazare (talkcontribs)

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)

AKlapper (WMF) (talkcontribs)

@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.

HaussmannSaintLazare (talkcontribs)

(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)

AKlapper (WMF) (talkcontribs)

@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!

AKlapper (WMF) (talkcontribs)

...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 :)

Can my Phabricator account be deleted?

3
Summary by AKlapper (WMF)

Yes, as it has been unused.

Tc14Hd (talkcontribs)

I accidentally entered a wrong email address at the registration.

I post here because Talk:Phabricator/Help is protected and I can't post.

AKlapper (WMF) (talkcontribs)

Sure! Done.

Tc14Hd (talkcontribs)

Thank you

There are no older topics