Project management tools/Review/Requirements

Phabricator

---

• Help

---

Edit

This is a consolidated summary of requirements provided by users. It was assembled by grouping similar requirements and sorting them by topic. When the same requirement was added as both a 'must-have' and a 'nice-to-have,' it's only listed once as a 'must-have.' Some requirements conflict with each other; those conflicts will need to be resolved by community discussion.

Current situation

Discussions and progress are scattered across a lot of tools. Bugs and features are sometimes tracked simultaneously in Mingle/Trello, Bugzilla, and Gerrit. Discussions happen across all of these platforms, plus via mailing lists, hangouts, Flow pages, and IRC. This has the effect of making our conversations regarding any progress completely disjointed, especially for tasks that take weeks to complete, because the discussion history can be incredibly hard to track.[1] Users would like to do all the things that they need to do in one place, not six (Mingle, Bugzilla, Gerrit, IRC, Translatewiki, Mediawiki.org) or more.[2][3]

Meta

Users must be able to:

Use this single system for all projects, configurations, discussions, designs and others (no roll-your-own-process with Mingle, or Github, etc.) [4] [5] [6] [7] [8] [9]

Be able to know what exactly the tool does and at least have a possibility of fixing it if necessary, that means: must be free and open source software and not outsourced [10] [11]

Users would like to be able to:

Discuss with another user outside a specific item [12]

Centralize discussion in one place [13]

Workflow

Users must be able to:

Alter the workflow at any time to accommodate new needs [14] [15]

Set custom swim lanes [16]

Set story points [17]

Track estimations [18]

Enforce certain actions be taken when a card's status changes — e. g.: ensure ownership changes happen seamlessly when a card's status changes; ensure that comments be added when a particular status gets updated [19]

Users would like to be able to:

Write a narrative of the important changes for a milestone (linking to tasks and commits alike) and series of milestones [20]

Handle Operations and Office IT tickets in the same system [21]

Visualization

Users must be able to:

Create custom item views, and save them for future use — e.g.: "All reopened Flow bugs" [22] [23][24] [25] [26] [27] [28] [29] [30]

See the current sprint's swim lanes [31]

Track velocity for a particular sprint as well as over an arbitrary length of time/number of iterations [32] [33] [34] [35]

Separate planned velocity from emergency velocity [36]

Generate burnup/burndown charts [37] [38] [39] [40]

Work in the emergency work trend [41]

View a dashboard for the review of incoming streams of, custom saved searches of, and individual item (task, commit) [42]

Users would like to be able to:

See helpful graphs and reports [43] [44]

Have a tech trend graph that can be manipulated in real time [45]

Organization and queries

Users must be able to:

Define a task's type (bug, feature, technical debt/code quality, enhancement) and query on that type [46] [47] / UI that is specifically made for tracking requests (software bug reports are just a subset of requests, bugtracker tools are specialized version of request trackers). [48]

Tag items in a free-form way, display tags [49] [50] [51], and query on that tag [52] [53] [54]

Display statuses — e. g.: for deployment, or blocked items [55] [56] [57]

Query tickets and commits by product, component, status, assignee, keywords, relationships, codebase, sprint/iteration [58] [59] [60] [61] [62] [63] [64] [65] [66] / Search code review, bugs, user stories, translation discussions [67] [68]

Add and edit relationships between the item and one or more other items (hierarchy, super-task/sub-task, dependency, bug <-> commit; also cross-project), automatically if possible [69] [70] [71] [72] [73] [74] [75] [76] [77] [78] / Associate items with external items [79]

Assign an item to a user [80] [81] [82] [83] [84] [85]

Assign a ticket to a (dated) milestone / sprint [86] / Add deadlines to items [87]

Accept and reject — e. g.: mark as invalid/wontfix) an item (with justification) [88] [89]

Rank/order/prioritize bugs and stories and do this across types —  e. g.: not only prioritize stories and prioritize bugs, but also prioritized bugs/stories relative to each other) [90]

Users would like to be able to:

Assign an item to a group instead of an individual [91]

Editing

Users must be able to:

Create new item (feature, task, bug) [92] [93] [94] [95]

Create an ultra-simple (default?) item entry type, which ideally would not even present anything beyond title and description. [96]

Edit an item [97] [98] [99]

Discuss an item [100]

Manipulate cards visually in swim lanes [101]

Merge, split, broaden or narrow a ticket [102]

Users would like to be able to:

Item content

Users must be able to:

Mark a task as "blocked" (with comments) [103] / Mark items as 'not actionable' [104] / Mark item as needing more input from a user [105] [106]

Edit type, priority, status, assignees, title, product/component, priority, confirmation, wording, details/comments of items [107] [108] [109]

Attach files — e. g.: a design image — to an item [110] [111]

Moderate tickets — e. g.: to hide comments [112]

Users would like to be able to:

Add checklists to items [113]

Define arbitrary properties for tickets [114] [115]

Monitor and report project results and objective criteria achievement [116]

Attach code to tickets [117]

History

Users must be able to:

View who created an item, and who was working on it last [118] [119]

View the history of charges in a item's life cycle (creation, major swim lane moves like 'Pending Code Review' and 'Deployed,' change of priority/keyword, etc.) [120] [121] [122]

Get a complete — i. e.: mostly automated — list, if not explanatory release notes, for all relevant items included in any given release/deploy of their interest. [123] [124] [125] [126] [127]

Users would like to be able to:

View a ticket's history in place [128]

Source code

Users must be able to:

Review and approve code before merging into master [129]

Interact with a git instance [130]

Restrict code merge ability to team members [131] [132]

Run automated checks (linting, etc.) and tests (unit, integration, browser, …) when code commits are submitted, amended, and approved (and block merge on this basis) [133]

Edit patches/code in their browser [134]

Automatically RESOLVE bugs when the code is merged, maybe using "Closes Bug: ####" as commit message [135] [136]

Configure automated testing for each project independently, which can be required for merge (voting, which is preferred), or not required for merge (non-voting, ideally temporary) [137]

Comment on a change/issue (cover comment) inline [138]

Users would like to be able to:

Automatically mark issues and features as 'deployed to production' when they are deployed [139]

Access

Users must be able to:

Restrict user read and/or write access to certain tickets, groups, and repositories [140] [141] [142] [143] [144]

Restrict write access to certain properties of an item (type, status, priority) and actions (create/modify stories, administer project settings) to some users (assignee, team) [145] [146] [147] [148] [149]

Allow any user to file a new bug [150] [151] [152]

Let anyone (who isn't a spammer/vandal) comment on the bug [153]

Let anyone read any (non-private) task ticket and all statuses [154] [155] [156] [157]

Have equal permissions even if they're just new users, rather than being punished for registering an account after year 200x (example for bugzilla: let all editbugs users add editbugs to other users.) [158]

Users would like to be able to:

Lock an item from further discussion once closed (maybe after some period of time?) [159]

Allow any user to generate an idea for a new user story [160]

File a task using their SUL login transparently [161] [162]

Let anyone express mere '+1' in the form of votes, so that they don't clutter the discussion. [163]

Interface

Users must be able to:

Add stories through desktop, mobile, tablet [164] [165] / Track requests to my team and me in a web-based UI. [166]

See real time changes without reloading the web page for a sprint [167]

See everything that is happening within a sprint without scrolling the screen [168]

Have one area for the backlog, one area for the current sprint, and one area for the upcoming sprint [169] [170]

Change columns being displayed [171]

Users would like to be able to:

Clearly see when someone else is updating a story or bug (like, updating the text of the description). Even better, it would be awesome if there were real-time updates to story/bug descriptions and status changes (without refreshing the page manually) [172]

Indicate user names in other venues (other tools, IRC, wiki, external sites) [173]

Notifications and API

Users must be able to:

Provide stable, simple, short-as-possible sharable URLs that uniquely identify tickets without login [174] [175] [176]

Transmit all needed streams of tickets and code commits by e-mail to users that need it [177]

CC people (including themselves, as a watch/follow/subscribe feature) without them being considered assigned [178] [179]

Receive email notifications whenever a bug which they have filed, to which they have assigned themselves or been assigned by somebody else, or to which they have 'CC'ed on is updated [180] [181] [182]

Be notified when new items are created or task status changes [183]

Notify user automatically when an item has been assigned to him or her [184] [185] [186] [187] [188] [189]

Notify user when an item has been marked as needing more input from that user [190] [191]

Use a real-time notifications feed, preferably IRC [192]

Get and send information about commits and tickets automatically on IRC [193] [194]

Use a read/write API provided by the tool [195] [196] [197]

Work without waiting too long for the tool to load [198]

Be notified when code goes to production [199]

Export all of our data (users, stories, etc) in a generic/commonly used format (like CSV) [200]

Get notifications based on arbitrary property changes — e. g.: a story has been moved to 'ready for signoff' and I receive an email alerting me to this fact [201]

Users would like to be able to:

Be able to control an entire ticket flow from the git command line [202]

Run scripts to batch-edit items [203]

Receive by e-mail and be able to review incoming streams, custom saved searches, and individual translations of discussions [204]

'Mute' a thread to stop receiving notifications about it, regardless of anything else [205]

See the status/title of the bug when it's linked to from a wiki page [206]

Export arbitrary chunks of data in a generic/commonly used format (like CSV) [207]

Use a mobile app (Android and iOS) to be able to get notifications, update tasks, etc. [208]

Edit a ticket by replying to a notification email [209]