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

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.

Is there a better way?

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)

Nemo_bis: 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 mw:Phabricator/Project_management#Setting_task_priorities (which I'd also describe as "has consensus" because IMHO it's not very different from mw:Bugzilla/Fields#Priority) 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)

Ggellerman (WMF): Yes, that sounds reasonable. Would you like to edit Phabricator/Project_management#Boards by adding a sentence? :) --AKlapper (WMF) (talk) 16:07, 9 December 2014 (UTC)

Ggellerman (WMF) and AKlapper (WMF) 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". Awjrichards (WMF), 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)

Qgil-WMF 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)

Qgil-WMF 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.[1] 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#Name 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)

@Polybuildr: I think the only historical reference from Bugzilla times that I am aware of is mw:Bugzilla/Fields#Priority. (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)

I completely agree.

Priority of a fix should be based on the IMPORTANCE of the functionality, or the SEVERITY of the bug.

Priority should NOT be based on whether or not someone volunteers to do it. That has nothing to do with priority.

For example, if a bug BREAKS the wiki, but nobody volunteers to work on it, we don't say it's Low Priority.

The section on this page, explaining priority, mixes the two concepts (importance vs assignment), thus creating a mixed up, confused definition. --Johnywhy (talk) 12:17, 26 May 2018 (UTC)

For context, until 2014 Wikimedia used Bugzilla which had two parameters called 'Priority' and 'Severity' so there were even more discussions about "correct assessment". Indeed the current definition is not super clear. I do not believe there will ever be a perfect definition that will not collide with adding many more fields (Impact vs Risk vs Urgency vs ...) that only a small minority will ever set. Keep it simple vs. having a clear way to express everything and anything, so to say. (Note that this is my private opinion, based on having spent lots of time in task tracking systems.) --AKlapper (WMF) (talk) 12:49, 26 May 2018 (UTC)

@AKlapper true there will never be a "perfect" definition. But the difference between priority INDEPENDENT of volunteer support, vs priority DEPENDENT on volunteer support ARE FUNDAMENTAL. That is NOT the difference between "perfect" and "less than perfect." It's a completely and totally different definition. Your language about "perfection" blurs and obscures the vast difference between the two. --Johnywhy (talk) 12:04, 30 May 2018 (UTC)

@Johnywhy: That requires defining "volunteer support" as I might not know what you mean exactly and/or which type(s) of "volunteers". --AKlapper (WMF) (talk) 09:59, 31 May 2018 (UTC)

@Johnywhy: Unrelated: Could you please sign your comments and use indentation? Keeps things more readable and accountable for everybody. Thanks! --AKlapper (WMF) (talk) 10:01, 31 May 2018 (UTC)

• What's wrong with discussion? It seems you're trying to silence discourage opinions that disagree with yours, by stifling discussion.
• In your Bugzilla link, neither Priority nor Severity are based on whether or not someone volunteered to work on it.
• In an effort to "reduce effort", inept, short-sighted, and inexperienced managers insist on keeping the very elements which create MORE work and effort in the long-run. That seems to be your position. I once debugged software used to manage a large infrastructure project for a leading global company. The software (designed by someone else) created lots of extra effort for staff, and generated tons of wasteful printouts. A few design changes that i proposed would have eliminated all of that extra effort and wasted paper. My inept, inexperienced manager, in an effort to "reduce effort", refused the design changes that would actually have reduced effort. As a result, teams were saddled with software which made their jobs harder and more time-consuming, not easier or faster.
• I use the word "volunteer" as you use the word here.
• Here are some perspectives on priority-setting in software dev. None mention "someone is working on it" as a way to determine priority. The reverse is true-- priority should determine whether someone should work on it.

> The "Must" requirements are non-negotiable, if they are not delivered then the project is a failure, therefore it is in everybody's interest to agree what can be delivered and will be useful. Nice to have features are classified in the other categories of "Should" and "Could.
> https://www.coleyconsulting.co.uk/moscow.htm

> Look at the usage data in your applications and prioritize bugs according to their relative impact on your application’s performance.
> http://sandhill.com/article/the-benefits-of-continuous-delivery/

> Analyze key areas that are taken into account before taking an important decision
> Benefit – an advantage that the business gets as a result of the required implementation. 
> Penalty – a consequence of not implementing a requirement. 
> Cost – effort and resources that are required to implement a requirement. 
> Risk – a probability that the requirement might not deliver the expected value. 
> Dependencies – a relationship between requirements, for example when requirement will require the completion of another requirement for its implementation.
> Time sensitivity – expiry date, urgency. 
> Stability – the likelihood of the requirement remaining static.
> Policy Compliance – requirements that must be implemented to meet the regulatory requirements.
> https://apiumhub.com/tech-blog-barcelona/software-requirements-prioritization-techniques/

If people don't assume well and accuse me of "trying to silence opinions" by "stiflling discussion" because I ask for a clarification, then engaging in a conversation with people who communicate with me in this tone does not look like a good use of my time. Cheers, --AKlapper (WMF) (talk) 14:35, 1 June 2018 (UTC)

Ok, "discourage" would have been a better word than "silence". But, I interpreted your comment below to mean "more discussion will not bring a more perfect definition, so there's no point in trying to improve it." I don't see any other way to interpret it. What did you mean, then?:

AKlapper (WMF): there were even more discussions about "correct assessment". Indeed the current definition is not super clear. I do not believe there will ever be a perfect definition

--Johnywhy (talk) 13:33, 1 June 2018 (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)

@André Costa (WMSE): 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)

• @MBinder (WMF): 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)
  • @AKlapper (WMF): 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)
    • @MBinder (WMF): The page currently says "Types deprecated by Milestones (there can still be valid reasons to have such "detached" top-level projects though, if milestones do not fulfill your needs)". If you can describe or link to these needs, feel free to "describe normally". :) --AKlapper (WMF) (talk) 10:04, 2 December 2016 (UTC)
      • @AKlapper (WMF): I tweaked it slightly, but otherwise I think it will do

https://www.mediawiki.org/w/index.php?title=Phabricator%2FProject_management&type=revision&diff=2300016&oldid=2299198. Thanks for taking the time to talk through it. :) -- MBinder (WMF) (talk) 23:12, 02 December 2016 (UTC)

• • • • • Thank you, anonymous editor! ;-) Looks good to me! --AKlapper (WMF) (talk) 10:21, 3 December 2016 (UTC)

Custom icon and colour for projects

We have a tag type project, specifically for our WMSE project, and it would be nice to make it stand out. Is it allowed to change icon and/or colour to a combination that doesn't collide with any of the combinations defined under Types of Projects? In this case, we'd like to have something like the tag icon and a colour that's not yellow. /Sebastian Berlin (WMSE) (talk) 09:18, 2 February 2017 (UTC)

@Sebastian Berlin (WMSE): You actually have an umbrella project, not a yellow tag one. :) I could imagine that the project could be seen as a team (group) and hence become violet? :P --AKlapper (WMF) (talk) 16:19, 3 February 2017 (UTC)

What I meant was that we have "tag" projects (subprojects to the WMSE project), that we like to add to tasks in any other project under WMSE. These "tag" projects are the ones we'd like to change icon/colour for. An example off these is WMSE-Communication. /Sebastian Berlin (WMSE) (talk) 09:40, 5 February 2017 (UTC)

@Sebastian Berlin (WMSE): Tag projects are yellow and have a tag icon. I get lost in what you mean. :( WMSE-Communication is a normal default "component" subproject; it is not a "tag" project in Phab terms. Again I'd recommend to change the color and icon for the "WMSE" parent project instead to violet/team and keep those subprojects as blue (as that sounds like in sync with the guidelines while using tag icons for something that is not cross-component does not)...? --AKlapper (WMF) (talk) 11:09, 6 February 2017 (UTC)

WMSE-Communication is technically a subproject of WMSE and not a Tag Project. We will, however, use it like a Tag Project, but only for tasks within WMSE and it's subprojects. We would like to have an easy way to distinguish these WMSE specific, quasi tag projects from other subprojects. /Sebastian Berlin (WMSE) (talk) 08:05, 9 February 2017 (UTC)

To allow distinguishing I proposed to turn the "WMSE" parent project into a violet/team project. --AKlapper (WMF) (talk) 10:40, 9 February 2017 (UTC)

We also want to distinguish from other subprojects of WMSE. /Sebastian Berlin (WMSE) (talk) 11:09, 9 February 2017 (UTC)

@Sebastian Berlin (WMSE): So if I get it right you "just" want a different color for "WMSE-Communication" to distinguish from other WMSE-* projects? I don't think that our guidelines currently support this, however we already have some yellow tags which should not be yellow tags as they are not completely organization wide projects either... Personally I would not revert if you did, however I cannot promise that the project color/tag would stay like that forever... --AKlapper (WMF) (talk) 17:01, 17 February 2017 (UTC)

Ok, then I'll try changing it and see if someone else complains. Thanks for the support. /Sebastian Berlin (WMSE) (talk) 09:02, 20 February 2017 (UTC)

Progress with subprojects

Phabricator/Project management#Parent Projects, Subprojects and Milestones (weird uppercase, by the way) has some documentation (see phabricator:T859#779997 for earlier discussions) and judging from phabricator:T123078 the practice is rather established, but where can I get an overview of the progress in creation of parent projects? (Perhaps the task creation link should include a tracking task.)

Example of subprojects work I found: phabricator:T138975, phabricator:T119944#3035777, phabricator:T128136, phabricator:T137816, phabricator:T95186. Most of the projects which I'd expect to be subprojects of something else still aren't, and I didn't understand whether I just need to wait a bit more. --Nemo 07:54, 17 February 2017 (UTC)

@Nemo bis: Not sure I understand "the progress in creation of parent projects" correctly but there is a log of the latest projects created. (If that's what you're asking for?) --AKlapper (WMF) (talk) 12:16, 17 February 2017 (UTC)

Renaming columns

Is it possible to rename columns on a workboard? (I wanted to rename the Wikimedia prod/labs issues to Wikimedia prod/Cloud Services issues but couldn't find a way to do so.) Dalba 09:33, 23 April 2018 (UTC)

You can do this from "Edit Column" in the column menu (accessible by the little down arrow to the far right in the column header). /Sebastian Berlin (WMSE) (talk) 09:39, 23 April 2018 (UTC)

How users could set a priority?

Hi, Following phab:T219589 and several older issues, there is a need for users to report how serious (or not) is a bug for them. Specifically this should be a different field that the priority sets by developers. I don't know the inside of Phabricator, so I don't know if and how such an adaptation is possible. I think this would also help developers to answer better to community expectations. Regards, Yann (talk) 16:37, 11 April 2019 (UTC)

Moving columns

Hi User:AKlapper (WMF), I think I couldn't find this answer in the documentation. I have just created a new column in my workboard and I simply want to move it to the left side of the page so that it's the second column that can be seen when opening the page, is this even possible? Thanks. Elitre (WMF) (talk) 15:29, 12 May 2020 (UTC)

Also, additional question. Is there any way I can make that column show up both in the main workboard and in each milestone's workboard? (Think of it as containing all the epics/umbrella tasks) If not, is there a way in which I can still achieve that? Thanks again. Elitre (WMF) (talk) 15:33, 12 May 2020 (UTC)

@Elitre (WMF): Heja! 1) Yes, documented now. 2) Not that I know, but I don't understand the use case yet. Could you elaborate / link to a specific example if possible? (You can see both a column of a parent project and the (single) milestone column on the parent project's workboard, but not the columns of the milestone project's workboard obviously.) --AKlapper (WMF) (talk) 19:20, 12 May 2020 (UTC)

User:AKlapper (WMF), I want to fill this column with the main projects that my team supports (tasks such as "Support Desktop Improvements in 2020" - stuff that is going to remain pretty stable throughout multiple quarters, but which is an umbrella to several smaller pieces thru the various quarter). Hence, I would like to be able to see it both when I am on the main workboard, and when I am in the various milestones workboard. HTH, Elitre (WMF) (talk) 19:58, 12 May 2020 (UTC)

@Elitre (WMF): I don't think this is possible. I'm afraid you'll have to use the parent workboard for this which displays both the column with the main projects, and the milestones (as one column each). --AKlapper (WMF) (talk) 21:08, 13 May 2020 (UTC)

Project watcher vs project member

I'm wondering what the difference is between a project watcher and a project member? I perused this page and I didn't see it. If it's not on the page, perhaps it can be added. Thanks! –Novem Linguae (talk) 01:57, 28 December 2023 (UTC)

Hypothesis: need to be a member to modify project workboards. Result: false. As a non-member, I can change things on workboards, perhaps because of my Trusted Contributor group.

Hypothesis: members do not receive emails on ticket changes, only watchers. Result: in progress. True. I received no emails from being a member and not a watcher. –Novem Linguae (talk) 22:14, 11 January 2024 (UTC)

This hypothesis should prove true for you.

For most projects in Wikimedia's Phabricator being a project member doesn't mean anything. There are however projects like #Trusted-Contributors and #acl*userdisable that are used as access control for something. See Phabricator/Permissions#ACL groups for more on that aspect. -- BDavis (WMF) (talk) 00:08, 12 January 2024 (UTC)