Issue Display & Sort Order Survey
Researcher Task List
-
Write survey questions -
Import survey questions into SurveyMonkey -
Test survey logic -
Write email to accompany survey -
Distribute survey to a test sample of users -
Review answers and make any necessary amendments -
Distribute survey to the rest of the research panel -
Purchase Amazon vouchers, conduct prize draw and contact winners -
Analyse survey results -
Write up findings -
Update relevant issues in the CE project
Research Questions
Issues boards
-
Should issues that are within the 'Closed' column appear in the order in which they were closed i.e. most recently closed issues appear at the top of the column?
-
If the proposed solution (ordering the 'Closed' column by most recently closed issues) is implemented. Will users still need the ability to manually re-order the 'Closed' column?
-
Does it matter if a 'Closed' column behaves differently from the 'Backlog' and label columns?
-
What information do users want to see on a card?
-
Does the information users want to see on a card differ depending on their job role or the GitLab product they are using?
-
How does the frequency of visiting an issues board affect what information users want to be displayed on a card?
Issues list
-
What information do users want to see within a list view?
-
Is the information users want to see within a list view consistent across all list views (dashboard, project and group)?
-
Does the information users want to see within a list view differ depending on their job role or the GitLab product they are using?
-
How does the frequency of visiting a list view affect what information users want to be displayed?
People who aren't using issues
-
Why aren't they using them?
-
If GitLab's issues are missing features - what features do users want?
Methodology
- Survey: http://bit.ly/2B7qTsD
- 127 respondents
Results
Issues boards
1. Should issues that are within the 'Closed' column appear in the order in which they were closed i.e. most recently closed issues appear at the top of the column?
Yes, 71% of respondents stated that their preferred sort order for the 'Closed' column was recently closed items appearing at the top of the column.
2. If the proposed solution (ordering the 'Closed' column by most recently closed issues) is implemented. Will users still need the ability to manually re-order the 'Closed' column?
No, only 13% of users would still need the ability to re-order the 'Closed' column.
3. Does it matter if a 'Closed' column behaves differently from the 'Backlog' and label columns?
No, it doesn't matter if the 'Closed' column behaves differently from the 'Backlog' and label columns.
59% of users confirmed that their backlog column is ordered by priority (defined by labels) with issues towards the top of the column being worked on first (71%).
61% of users confirmed that other label columns (such as 'Doing', 'QA', etc) are also ordered by priority (defined by labels).
Therefore the default order for these columns (priority) should remain as is.
Only 13% of users use the default order of priority for the closed column.
In conclusion, it is currently a hindrance to users that the 'Closed' column mimics the ordering of the other columns.
4. What information do users want to see on a card?
Note: This was a multiple choice question. Users could select as many items as they wanted.
In descending order:
| Content | % of users |
|---|---|
| Title | 77% |
| Assignees (people working on the issue) | 69% |
| Associated labels | 61% |
| Status (open, closed, etc) | 57% |
| Issue Number | 46% |
| Due date | 41% |
| Todo (whether the issue has a todo for you) | 38% |
| Weight (estimated size of the issue’s effort) | 34% |
| Author (who created the issue) | 31% |
| Days in column (the number of days an issue has remained in the same column) | 26% |
| Last updated relative timestamp (for example: updated 32 mins ago) | 24% |
| Tasks (number of pending/completed tasks in the issue) | 24% |
| Merge Requests (number of associated merge requests) | 23% |
| Milestone due date | 21% |
| Time spent (time tracked on the issue) | 20% |
| Milestone number | 19% |
| Thumbs up emoji (support/number of likes for the issue) | 18% |
| Estimated time (estimated time to resolve the issue) | 18% |
| Opened relative timestamp (for example: opened 32 mins ago) | 16% |
| Discussions (number of comments within the Discussions tab) | 15% |
| Last updated absolute timestamp (for example: updated 22nd Nov 2017) | 12% |
| Subscription (whether you’re receiving notifications about the issue) | 9% |
| Opened absolute timestamp (for example: opened 22nd Nov 2017) | 7% |
| Locked (whether the issue’s discussion has been locked) | 7% |
| Confidentiality (whether the issue is confidential) | 5% |
| Whether the issue is blocked | 1% |
| Should be configurable dependant on the needs of the project | 1% |
5. Does the information users want to see on a card differ depending on their job role or the GitLab product they are using?
There was very little difference in what users wanted to see on a card in relation to the GitLab product they are using. GitLab.com users were more likely to want to see whether the issue had a related todo for them (50%) in comparison to self-hosted and/or paid GitLab instances. Enterprise users also had a slightly higher dependency on assignees (85%) and labels (77%).
Your job role does affect what you would like to see on a card. Developers in non-managerial positions tended to want less content on cards. Assignees (69%), title (69%), associated labels (50%) and status (47%) were sufficient for their needs.
Development Team Leads requested the same content, but in comparison, had a much stronger requirement for it: Assignees (92%), title (92%), associated labels (92%) and status (58%). In addition, Development Team Leads wanted: due date (58%), days in column (50%), issue number (50%) and merge requests (42%).
A possible solution is to create two card views, one suited to Developers with less content/noise and one aimed at Team Leads which provides a more detailed overview of an issue.
6. How does the frequency of visiting an issues board affect what information users want to be displayed on a card?
There weren't any significant differences in the type of information that users want on a card in relation to how often they visited the board view. However, the more frequently a user visited the board view, the stronger their requirement for a particular piece of information was, in comparison to occasional users.
For example:
Users who always visit the board view: Title (92%) and Labels (66%).
Users who sometimes visit the board view: Title (61%) and Labels (43%).
Interestingly users who sometimes visit the board view said they wanted the issue status to be clearly displayed (72%) which was much higher than users who always visit the board view (42%). I wonder if this is because, in most cases, board column headings (labels) clearly indicate the issue status.
Issues list
1. What information do users want to see within a list view?
Note: This was a multiple choice question. Users could select as many items as they wanted.
In descending order:
| Content | % of users |
|---|---|
| Title | 79% |
| Assignees (people working on the issue) | 74% |
| Status (open, closed, etc) | 74% |
| Associated labels | 61% |
| Issue Number | 54% |
| Author (who created the issue) | 48% |
| Due date | 48% |
| Tasks (number of pending/completed tasks in the issue) | 48% |
| Last updated relative timestamp (for example: updated 32 mins ago) | 41% |
| Merge Requests (number of associated merge requests) | 39% |
| Todo (whether the issue has a todo for you) | 39% |
| Thumbs up emoji (support/number of likes for the issue) | 30% |
| Discussions (number of comments within the Discussions tab) | 29% |
| Weight (estimated size of the issue’s effort) | 28% |
| Milestone number | 26% |
| Milestone due date | 25% |
| Opened relative timestamp (for example: opened 32 mins ago) | 24% |
| Time spent (time tracked on the issue) | 20% |
| Last updated absolute timestamp (for example: updated 22nd Nov 2017) | 18% |
| Estimated time (estimated time to resolve the issue) | 18% |
| Subscription (whether you’re receiving notifications about the issue) | 14% |
| Opened absolute timestamp (for example: opened 22nd Nov 2017) | 13% |
| Confidentiality (whether the issue is confidential) | 10% |
| Locked (whether the issue’s discussion has been locked) | 9% |
| Whether the issue is blocked | 1% |
| Should be configurable dependant on the needs of the project | 1% |
| Link to project (from Group issues list) | 1% |
2. Is the information users want to see within a list view consistent across all list views (dashboard, project and group)?
Yes, there was very little difference in what users wanted to see at a dashboard, project or group level.
When users were asked which of the following list views they look at the most, the majority of users specified the project view (76%), followed by personal dashboard (20%) and finally group view (4%).
3. Does the information users want to see within a list view differ depending on their job role or the GitLab product they are using?
Yes, Enterprise users tended to want more information in the list view.
At a bare minimum users of any GitLab product want to see the following information in the list view:
- Title
- Status
- Assignees
- Associated labels
Users of GitLab.com want:
- Tasks (61% of .com only users, there was very little interest from CE or Enterprise users)
Users of CE and Enterprise want:
- Issue Number (60% of CE only users, 69% of Enterprise only users).
Enterprise users want:
- Merge Requests (69% of Enterprise only users)
- Milestone number (62% of Enterprise only users)
- Due date (61% of Enterprise only users)
- Author (54% of Enterprise only users)
- Thumbs up emoji (54% of Enterprise only users)
- Discussions (54% of Enterprise only users)
- Last updated relative timestamp (54% of Enterprise only users)
Job role also affected what information a user would like to see in a list view. Similarly to the card view, developers in non-managerial positions tended to want less content in the list. Assignees (73%), status (70%), title (67%) and tasks (54%) were sufficient for their needs.
Development Team Leads requested:
- Labels - 92%
- Assignees - 83%
- Title - 83%
- Status - 75%
- Merge Requests - 67%
- Author - 67%
- Issue Number - 58%
- Due date - 58%
- Last updated relative timestamp - 50%
Just to note: I cross-referenced the number of Development Team Leads against each GitLab product to ensure each set of results weren't influencing one another in any way. They are not. We had an almost even split of Development Team Leads using each GitLab product.
4. How does the frequency of visiting a list view affect what information users want to be displayed?
There weren't any significant differences in the type of information that users want in a list view in relation to how often they visit it.
People who aren't using issues
1. Why aren't they using them?
26% of users who answered the survey did not use GitLab issues. Of those users, 31% stated that their primary reason for not doing so was because they were 'happy with their current issue solution/provider.' In the majority of cases (67%) users' current issue solution/provider was JIRA.
2. If GitLab's issues are missing features - what features do users want?
Of the users who did not use GitLab issues, only 14% stated that their primary reason for not doing so was due to 'missing features'. When asked what features were missing from GitLab, only three users provided comments. Their suggestions were as follows:
"Most of the features in the portfolio management piece. Specifically anything related to epics, issue flow (blocked issues, grouped issues, etc), ability to do rollups of issues to get status on a much larger 'application', product planning, etc. The developer interaction story w/ issues is fairly solid, but all the pieces needed for scrum masters, product managers, product managers, etc are completely missing."
"We use tasks to track time and to see different reports. Issues serve a different purpose, and duplicating info from tasks to issues is not reasonable."
"We currently have around 80 different Projects, all our in-house software. We have issues in most of them but gitlab-community-edition has no global issue overview, so it is very difficult to see all issues in all projects and manage them."