Talk:Phabricator/Project management

Moving tasks on boards
This is a really painful UI! On https://phabricator.wikimedia.org/project/board/87/, the backlog is very large, and to move a backlog item to a different column I need to (using Chrome): Is there a better way?
 * 1) move it up to the top of the backlog, which involves repeatedly moving it up from bottom of the screen to the top of the screen, releasing it each time. There is some scrolling capability, but it causes the selection to be lost.
 * 2) move it across to the desired column.

I see at least one feature request about this: https://secure.phabricator.com/T6027 John Vandenberg (talk) 07:07, 29 November 2014 (UTC)
 * Hello?? This is painful!  Surely I am doing it wrong? John Vandenberg (talk) 17:14, 4 December 2014 (UTC)
 * In Firefox 33 I left-click (and keep clicked) on the last/lowest card in the Backlog column, move it to the right, scroll up, and release the left-click. Hence no "releasing it each time" needed here... --AKlapper (WMF) (talk) 17:43, 4 December 2014 (UTC)
 * Ah! Moving it to the right fixes my problem in Chrome also.  Thx! John Vandenberg (talk) 17:47, 4 December 2014 (UTC)

Another approach is to pull the item of the column using the mouse, and then use page-up to move to the top, and arrows to move across to columns not visible if required, before dropping the item. This wasnt immediately obvious to me. Hope that helps someone else. John Vandenberg (talk) 04:44, 14 February 2015 (UTC)

A recently-added feature in phabricator allows moving tasks to a different column using a dropdown control instead of dragging. When viewing a task, down at the bottom where you can add a comment, you can now choose to "move on workboard", and choose the destination column from the list. - KSmith (WMF) (talk) 16:10, 29 June 2016 (UTC)

You
Who is "you"? --Nemo 18:59, 8 December 2014 (UTC)
 * What's the context? --AKlapper (WMF) (talk) 19:32, 8 December 2014 (UTC)
 * Well, if you refer to the entire content of the page, then you is the reader of the page. --AKlapper (WMF) (talk) 19:33, 8 December 2014 (UTC)
 * Really? Let's see.
 * I don't: "have a new project"; have the ability to "create a 'project' in Phabricator"; have a "your team" or "your sprint"; "plan to work on in the current sprint".
 * It's impossible that "you are still planning to work on it" or "are explicitly saying" applies to all readers at the same time, or even a majority.
 * For any task, it's true that a supermajority of readers "don't plan to work on this task, even if [they] would be happy if someone does".
 * --Nemo 20:22, 8 December 2014 (UTC)
 * What is the problem that you'd like to see solved? Some initial sentence who should not bother to read the page, or something else? The page name is "project management" so if you are interested in project management, how would you like to be addressed to (not) read on? :) --AKlapper (WMF) (talk) 20:53, 8 December 2014 (UTC)
 * The problem I want to see addressed is that bug properties are not well defined. --Nemo 09:38, 9 December 2014 (UTC)

I'm still unable to use priority. If this issue is not addressed, I'll rephrase myself to match something usable as what we used to have (which also had consensus). --Nemo 18:22, 4 January 2015 (UTC)
 * There is Phabricator/Project_management (which I'd also describe as "has consensus" because IMHO it's not very different from Bugzilla/Fields) and no project maintainers have changed it yet. I mostly remember what "well defined" meant in mathematics (though that Wikipedia page was helpful to refresh it), but I'm not sure how to apply that to software project management. Please feel free to elaborate the practical problem. In any case, I believe we should use the lowest available priority level way more often than we did in Bugzilla, simply because it's more realistic in a world with limited (wo)manpower. But I'm not sure if that has anything to do with your question. :-/ --AKlapper (WMF) (talk) 00:53, 5 January 2015 (UTC)


 * Is "you" the person who creates a task, or the person who assigns a task to itself? -- FriedhelmW (talk) 16:32, 22 January 2015 (UTC)
 * Rather the latter. I've naively tried to clarify a bit in very the first sentence by using the words "maintain" and "manage", wondering whether that really made things a little bit clearer here. --AKlapper (WMF) (talk) 06:39, 24 January 2015 (UTC)

Question: can projects be unarchived?
This functionality could be useful Ggellerman (WMF) (talk) 21:35, 8 December 2014 (UTC)
 * Yes, members of the Project-Creators group can "Edit Details" of a project and click "Unarchive project". --AKlapper (WMF) (talk) 16:04, 9 December 2014 (UTC)

Backlog as public face of project
Should we remind users that a Phabricator backlog is not just a means to manage a project's work, but it's also a communication tool. Other stakeholders may look at it, and tasks in it should be written in understandable language. Ggellerman (WMF) (talk) 21:44, 8 December 2014 (UTC)
 * Yes, that sounds reasonable. Would you like to edit Phabricator/Project_management by adding a sentence? :) --AKlapper (WMF) (talk) 16:07, 9 December 2014 (UTC)
 * and this is done with https://www.mediawiki.org/w/index.php?title=Phabricator%2FProject_management&diff=1312920&oldid=1312911 Awjrichards (WMF) (talk) 17:33, 12 December 2014 (UTC)

Document Blocking tasks
There is a feature that allows you to indicate in a task if another task is blocked pending its completion. We should document how to use it. Ggellerman (WMF) (talk) 21:47, 8 December 2014 (UTC)
 * Good point! Covered now by https://www.mediawiki.org/w/index.php?title=Phabricator%2FProject_management&diff=1308480&oldid=1308478 - feel free to improve if something is unclear. --AKlapper (WMF) (talk) 16:15, 9 December 2014 (UTC)

Do we need to refer to tasks as 'tasks' in the document?
"This article will use single quotes around the word 'task' to differentiate the concept of a 'task' in Phabricator from standard uses of the word". , do we really need this? We didn't need to type single quotes around 'bug' in the entire life of Bugzilla documentation, an there the original meaning differs a lot more. Same with Trello 'cards' and 'boards' and long etc. I find these single quotes annoying after reading a bit.--Qgil-WMF (talk) 11:38, 10 December 2014 (UTC)
 * I am not married to the use of single quotes around 'task' etc. However, I think it's useful to have a way to differentiate between a Phab task and a general task because a 'task' in Phabricator can be much more than a task - it can be a task, a user story, feature request, bug, ad infinitum; whereas bugs in Bugzilla were generally bugs (with the exception of feature requests; at least that was the case for the projects I worked in - though now that you mention it, I know I've seen bugs in BZ used for a whole lot more elsewhere). Having been the one to put the quotes around each use of the word, I can attest it was indeed a PITA, and I can understand it being annoying to read. Let's try getting rid of the single quotes and hope that the context is sufficient for readers to infer the appropriate meaning; we can find a way to disambiguate if need be in the future. Awjrichards (WMF) (talk) 17:01, 12 December 2014 (UTC)
 * I just took out the single quotes around 'task' and 'tasks'. I am of the opinion that 'projects' are much more useful to differentiate - are you OK keeping Phab projects in single quotes? Awjrichards (WMF) (talk) 17:08, 12 December 2014 (UTC)
 * Awjrichards (WMF) works for me. Thank you for the reasoning and the action.--Qgil-WMF (talk) 12:56, 13 December 2014 (UTC)

Uppercase tags
A number of tags have been created lately, for whatever reason. Most of them use inconsistent casing, i.e. begin with an uppercase letter. Why? Can we have a rule please? --Nemo 18:23, 4 January 2015 (UTC)
 * Is this about aesthetics or is there some usability issue that I am not aware of? --AKlapper (WMF) (talk) 00:42, 5 January 2015 (UTC)
 * (In)consistency is a usability issue: it causes confusion in the users. --Nemo 22:07, 6 January 2015 (UTC)
 * I'm not a fan of inconsistency either, but does the current situation cause any practical issues? Are there any statements that people do not add a project if it's lower case if similar projects are upper case? --AKlapper (WMF) (talk) 02:01, 7 January 2015 (UTC)
 * For what is worth, Phabricator/Creating_and_renaming_projects says "Title case by default".--Qgil-WMF (talk) 16:07, 7 January 2015 (UTC)
 * Looks like the keywords imported from Bugzilla and the vuln-* tags are lowercase, the rest is uppercase (how it should be). That's fixable. :) --AKlapper (WMF) (talk) 17:28, 8 January 2015 (UTC)
 * Should be fixed now. Thanks! --AKlapper (WMF) (talk) 18:11, 8 January 2015 (UTC)

Archived tag in use on this page
At the top of the page is #Project-Management, linking to https://phabricator.wikimedia.org/tag/project-management/ , which is flagged as Archived. Is Project Management no longer in use these days? :P John Vandenberg (talk) 04:46, 14 February 2015 (UTC)

Definition of task priority
Phabricator has the 'Unbreak Now', 'High', 'Normal', 'Low' and 'Lowest' priorities as options for tasks. And the "Priority levels" section here gives certain guidelines for what each of them means. However, apart from 'Unbreak Now' and 'Needs Triage' - whose definitions do make sense - the others, imho, don't really refer to a task's priority. The explanation says "High - Someone is working or planning to work on this task soon". Shouldn't the priority/urgency of a task be independent of whether someone is working or planning to work on a task soon? There are instances of "priority should be lower unless you are planning to work on it", but that doesn't really make sense, does it? Irrelevant of whether anybody is planning to work on it, a task is either high priority or it's not.

Also, another thing, slightly unrelated: Given an "average" bug, that's, say, mildly annoying but isn't breaking anything, what should its priority be? From what I've seen, it gets set to "Low", but then what does "Normal" really mean?

Overall, maybe we need a little discussion on what priority means, what it's being used for, and rethink the explanations of the current priority levels? --Polybuildr (talk) 18:55, 24 June 2015 (UTC)
 * This discussion on upstream phab seems relevant. --Polybuildr (talk) 19:49, 24 June 2015 (UTC)
 * Though I'm not entirely happy with the definitions either I'm afraid that we will never find a definition that everybody understands in the same way. Which doesn't mean that it should not be discussed - I'm always happy if there's agreement on improvements. :) I would have loved to rename "Normal" to "Medium" when we migrated from Bugzilla but somehow that fell of my list... :( --AKlapper (WMF) (talk) 14:39, 9 November 2015 (UTC)
 * The "Low" vs "Normal" issue is something that I think is still less important than the fact that a task's priority changes when a developer is working on it. The "importance"/priority/urgency of a task/bug really should have nothing to do with whether someone is working on it. Is there a historical (possibly Bugzilla-related) reason that this happens? -- Polybuildr (talk) 15:42, 9 November 2015 (UTC)
 * I think the only historical reference from Bugzilla times that I am aware of is Bugzilla/Fields. (And as noted in the thread below on this talk page, it's not that all teams use the field or use it consistently either.) --AKlapper (WMF) (talk) 20:13, 18 November 2015 (UTC)

Setting Priority in Phabricator
Hi, I was told here is the right place. ;o) So copying from Talk:WMF product development process.

There was recently a disagreement about what the "Priority" tag means in Phabricator. I learnt that developers change this when they mean to work on a given bug. This is not the purpose I expected. I initially thought that this means what the bug reporter thinks, i.e. what relative importance should be given to this bug. So we may need a new parameter, to enable volunteers who report and comment on bugs to express what they think, which obviously may not match what developers finally do. Regards, Yann (talk) 22:48, 8 November 2015 (UTC)
 * Thanks for sharing this. Reporters are very welcome to express in their initial task description what they think. No need for a new parameter. :) --AKlapper (WMF) (talk) 06:36, 9 November 2015 (UTC)
 * I had a serious issue with this too, as I wrote about in the section above this one. Unfortunately, no one got around to commenting after that. :/ -- Polybuildr (talk) 13:03, 9 November 2015 (UTC)
 * Some teams adjust the priority field to reflect their workflow. Others leave the priority field as it was, to reflect something closer to reporter-perceived urgency than priority. Others ignore the field entirely, and rely on the positions of tasks within columns to choose what to work on next. For what it's worth, I also don't like trying to track importance, urgency, and priority within a single field. --KSmith (WMF) (talk) 16:07, 9 November 2015 (UTC)

Documentation of creation of sub project
Just checking. There is no documentation requirment (as in phab:T103700) on the creation of sub-projects (and milestones)? /André Costa (WMSE) (talk) 14:54, 29 June 2016 (UTC)
 * no, there isn't. Once a main project has been created, its subprojects, milestones, etc, can be created directly. I have documented this practice here. Thank you for asking!--Qgil-WMF (talk) 07:20, 30 June 2016 (UTC)
 * Thanks for the quick response and the clarification. /André Costa (WMSE) (talk) 13:13, 30 June 2016 (UTC)

Sprints and Release Boards vs Milesontes and Subprojects
Howdy! :)

I came across this:

* Sprint is used for projects of a team being worked on in a certain time frame. Specify the start and end dates. It is recommended to create a Milestone of the sprint's parent project, instead of a separate detached Sprint project. Icon+Color: Timeline+Green. * Release is for planning a specific deployment of a project, defined by a date or a (future) software version. It is recommended to create a Milestone of the release's parent project, instead of a separate detached Release project. Icon+Color: Release+Orange.

I disagree with these recommendations if using them as a general guideline. I think there are valid times when teams use sprints but want tasks to remain in a unified backlog; as the tasks are resolved in the sprints, they are resolved from the backlog. If you use Milestones, you are forced to remove tasks from columns that may be used for categorization. If you use Subprojects, you cannot also tag the parent backlog.

The following is an example of what we use to do on Phabricator before the existence of Milestones (when we wanted similar visual organization):

[Task on backlog board column A] --> [Task moved to column B, such as "Current Sprint"] (Then we would manually move tasks on the backlog to reflect that they were in the sprint. This is still being done on https://phabricator.wikimedia.org/tag/reading-web-backlog/ and https://phabricator.wikimedia.org/tag/fundraising-backlog/ because Milestones also restrict other things teams like to do).

The following is an example of what we use to do on Phabricator before the existence of Subprojects (when we wanted similar visual organization): [Task on backlog board column A] --> [Task untagged with backlog board, then tagged another workboard, something like "Kanban"] (Tasks on https://phabricator.wikimedia.org/tag/wikipedia-ios-app-backlog/ used to do this with https://phabricator.wikimedia.org/tag/wikipedia-ios-app-development/ and now use a process similar to the previous example with Milestones).

TL;DR: I think if you want functionality that Milestones and Subprojects provides, then you might as well use them because it is automatic. However, saying that they supersede separated Sprint or Release projects is premature, because there exists functionality with those that does not with Milestones and Subprojects.

Just my two cents! :) -- MBinder (WMF) (talk) 03:54, 30 November 2016 (UTC)
 * Indeed, thanks! What is your recommendation? To have no recommendation? :) People need to make choices so I wonder how to rephrase without requiring everybody to fully understand the differences first between projects, subprojects and milestones. --AKlapper (WMF) (talk) 11:24, 1 December 2016 (UTC)
 * I agree that parsing the benefits and restrictions of Subprojects and Milestones vs similarly manual approaches is challenging, especially verbally. If the choice is to say "Subprojects and Milestones instead of separate projects, always" or to say no recommendation, I prefer the latter. If not, maybe we can describe Sprints and Releases normally, and also point to Subprojects and Milestones as features that may provide enhanced functionality (and corresponding restrictions)? -- MBinder (WMF) (talk) 00:25, 30 November 2016 (UTC)