As part of the processes revamp discovery, we’ve identified several topics to address and proposed solutions. To get an overview of the general attitude towards the proposals and to identify controversial ones requiring further discussion, I’ve set up a series of polls.
Please consider each summary of the issue and proposed solutions, and respond whether you think we should go ahead with the proposed solutions in general. For more details, please refer to the discovery. Feel free to respond to this thread or comment on the discovery doc if you wish to expand on your answer.
- Deadline: please respond by the end of the year.
- Time logging: please log time to your subtask of BB-10314.
1. Improve ping response
We have a strong policy of a 24h workday response time to pings. Sometimes pings have delayed responses or are missed. We propose:
- Document methods of reducing noise from too many notifications.
- Discuss Gmail filter effectiveness.
- Document guidelines for effective pinging (eg. reducing pings, directly mentioning people, etc.).
- Re-assert expectations for quick responses to pings.
- Yes
- No
- Undecided
2. Restructure the handbook
The handbook has areas that are difficult to read due to being very long or difficult to navigate. We propose:
- Audit the content, decide what we want to keep, remove, need to add.
- Work on a structure from the ground up (improving navigation, better categorisation, grouping content better, reducing verbosity, considering Diataxis principles, etc.).
- Yes
- No
- Undecided
3. Address worklog upload delays
Worklogs must be uploaded promptly (policy is within 24h), to help with planning and budgeting. Many members use third party tools to record time, then sync to Jira/Tempo later, which is fine. However there have been recurring issues with worklogs not uploaded promptly. We propose:
- Schedule a ticket for each member having issues syncing worklogs, to give them time to address blockers, improve their automation, etc.
- Improve documentation around worklog syncing automation tools, including supporting setup for non-technical members.
- Test and improve the syncing automation tools.
- Yes
- No
- Undecided
4. Reinstate retrospectives
Retrospectives are important, but have fallen by the wayside. We propose:
- Gathering retrospective comments in midsprint and end of sprint updates.
- Include prompts somewhere to help think about aspects to be retrospective about.
- Create a lightweight process for regularly discussing and addressing retrospective comments.
- Update all related documentation to be consistent with the new process.
- Yes
- No
- Undecided
5. Rethink estimation sessions
Estimation sessions have low attendance and possible aren’t useful any more anyway. We propose:
- Drop the estimation sessions.
- Define who is responsible for estimating and reviewing estimates for story points (probably will fall to reporters, epic owners, assignees, etc.).
- Add a point to the sprint process for reminding to browse tickets on the backlog to comment on, provide more context, or take.
- Schedule follow-up forum discussions: do we find story points useful? Is there anything we’re missing by not having estimation sessions?
- Yes
- No
- Undecided
6. Improve task standards in Jira
Task standards are important for ensuring tickets have context for everyone who needs them (assignee, reviewer, future assignees, future debugging, etc.). However, some standards are outdated, and sometimes the standards aren’t followed. We propose:
- Update the jira task and epic description templates, removing outdated fields.
- Make it clear that all tickets should uphold a standard.
- Define who is responsible for maintaining ticket descriptions (probably reporter, assignee, and reviewer, with a check-in by the sprint/planning manager).
- Yes
- No
- Undecided
7. Improve PR standards
PR standards are important for context, but sometimes they are not met. Also, the template we use is not flexible for all situations. We propose:
- Update the handbook’s pull requests info page.
- Make our own standard template and guidelines for PR descriptions (including for cases where we must use an upstream template). Mostly clarifying, not changing content so much.
- Add responsibility to the reviewer to review PR descriptions too.
- Yes
- No
- Undecided
8. Improve PR review standards
Likewise for reviews, our review template is outdated. We propose:
- Add checklist item for reviewing pull request description and title.
- Add checklist item for reviewing the commit message.
- Update the code drift checklist item.
- Yes
- No
- Undecided
9. Improve sprint updates attendance
Sprint updates are often late/missed, or missing the video component. We propose:
- Drop requirement for videos in end of sprint updates.
- Add a prompt somewhere for reminding members what to include in updates.
- Implement reminders before any deadlines for submitting updates.
- Yes
- No
- Undecided
10. Increase face contact
We don’t have much opportunity for interactive with colleagues apart from text. We propose:
- Provide flexibility for scheduling more social chats to cover more timezones. Use calendar events rsvp more, get consensus on more regular slots.
- Schedule a roster of somekind for different people to make a “show and tell” video each week (especially since we’re planning to drop videos in sprint updates).
- Yes
- No
- Undecided
11. Revise technical handbook sections
NOTE: unsure if this will be part of this epic, or part of STAR-3886.
Some sections of the handbook need to be used by everyone, but the tasks are explained in a very technical manner, making it less accessible to non-technical members. We propose:
- Identify processes in the handbook, private docs, listaflow checklists, etc. that are applicable to everyone but using technical language.
- Update the language and steps in these processes to be more accessible to a wider audience, and have them reviewed by non-technical members.
- Consider training for non-technical members in common tools like Git, Gitlab, etc.
- Yes
- No
- Undecided
12. Increase sprint checklist response rate
NOTE: this topic may require more discussion, as it appears that members use the checklist in different ways; it’s a complex topic.
Timely response rate for the sprint checklist is not bad, but there are always some late. There may be primary blockers (relating to listaflow) or secondary blockers (relating to the tasks to check off). We propose:
- Reduce the number and verbosity of checklist items.
- Add notifications for reminders.
- Make it clear in Listaflow which role a checklist item is for.
- Make the checklist items expanded by default where applicable.
- Review the checklist items to ensure they line up with the handbook.
- Yes
- No
- Undecided
13. Improve upstream PR review tracking
NOTE: this is already approved work, that we’re simply moving to this epic.
How can we make sure that comments from upstream reviewers don’t go unanswered for extended periods of time? These are for PRs associated with tickets in external review / blocker. We propose:
- Refine OSPR Liaison role, updating the handbook. Reassign the role.
- Obsolete parts of OSPR Liaison role identified and removed.
- Clarify how often external review/blocker tickets and long external review tickets should be checked by the sprint/planning manager.
- Yes
- No
- Undecided
14. Revise community relations roles
NOTE: this is already approved work, that we’re simply moving to this epic.
Volume of hours logged against Community Relations account is quite low (23h total in 2023). Maybe even too low to justify the additional overhead of regular epic management and budget tracking. We propose:
- Review and refine Community Liaison role.
- Come up with a budget for the two community relations roles.
- Decided if we should resume regular epic management for FAL-3511 so that we can track budget usage better.
- Create a new ticket with a different account for any existing ticket using the Community Relations account and is out of scope for the Community Relations epic.
- Yes
- No
- Undecided
15. Reduce sprint planning friction
This is a collection of things relating to quality of life for everyone’s sprint planning. We propose:
- For any messages from Sprint Bot, linkify Jira ticket IDs, and cleanly format any structure data.
- Document semantics of our Jira labels and “Fix Version/s”.
- Consider improving quality and timeliness of epic updates. This will be further discussion.
- Improve the vacation checklist for less friction and to encourage its use more. discuss.
- Disable Crafty’s behaviour of moving tickets to stretch goals where it detects an injection. Also consider updating the rules around injections, as they may be too strict.
- Yes
- No
- Undecided
16. Define blocked/unblocked states
There can be confusion and extra back and forth around determining if a ticket has budget available, is ready to be worked on, or why it’s in stretch goals, blocked, or backlog. We propose:
- Clarify and document how to mark tickets and blocked/unblocked on budget, blocked on external things, ready/not-ready to work on.
- Rename the “ready to pull in” version (label) to clarify intent better. Discuss with the team whether it’s effective, and perhaps remove it altogether.
- Clarify the purpose of the stretch goals sprint.
- Yes
- No
- Undecided
17. Maintain issues/PRs/repos backlogs
We have many repositories across Gitlab and Github, with many open issues and PRs. These can get outdated or missed. We propose:
- Expand an existing role to include periodic processing of old repositories, backlog of pull requests, and backlog of issues, checking for corresponding jira tickets for issues.
- Schedule a once-off large task to tidy the backlogs, before starting the more regular small process to keep it tidy.
- Yes
- No
- Undecided
Thank you for making it this far, your feedback is valuable!