The old process involved the “Core Contributor” field in Jira and/or recurring tickets in the sprint.
The new process: For any Core Contributor work (e.g. answering a question on the community forum, reviewing a team member’s upstream PR, reviewing a community PR, improving the devstack, helping with the Maple release, etc.), create a dedicated Jira ticket.
The account should be the client’s account (for team member upstream PRs), the accelerated epic’s account (if it’s an accelerated epic), or “Contributions” (for anything else).
For upstream PR reviews, the goal is still to review them in the same sprint as the work is done. There will just be a separate ticket to track the Core Contributor review.
Core Contributors: please start using this process next sprint. And in particular, please create tickets to plan 10 hours of work for Sprint 262 now, during Sprint 261.
Optional “FAQ”:
Q: Does this mean that we won’t use the “Core Contributor 1” field(s) in Jira anymore?
Right, we don’t need those anymore.
Q: For an upstream PR review, who creates the ticket - the Core Contributor or the original author?
It’s probably easier if the Core Contributor creates their own tickets. Ping them in a comment on the original ticket to ask if they can review, and if they are available they can create their own ticket for it, which will be linked to the original ticket.
Q: Won’t it be a hassle? Creating tickets in Jira is a bit of a pain compared to just setting the “Core Contributor” field
That’s why I created a bookmarklet so that as a Core Contributor, you can create a review ticket in just one click
Based on a quick look at the bookmarklet code it seems like it will set the project to MNG by default. If so, everyone except you and Xavier will need to remember to adjust the project of their CC tickets after creating them using the bookmarklet.
What I forgot to say was: Before saving the bookmarklet, you will need to edit the indicated line to set your cell That way, it will create tickets in the correct project, and there’ll be no need to change the project after creating the ticket.
Hi folks, @antoviaque pointed out that if we’re putting these tasks in a different epic, they won’t show up in your epic budgets if you use the “Epic Sum Up” tool (though they will if you do a budget report using the Account). Is that going to be a problem? Because if so we could switch to using a label instead of an epic to track all the Core Contributor tickets.
Ok, let’s switch to a label! How about “CoreContributor” (keep it simple).
I won’t have time to create a full PR or announcement for that change before my holidays, but feel free to use either that label or the epic in the mean time. And if someone else want to open a PR to update the handbook and the bookmarklet, please do. Otherwise I will do so when I’m back in January.
@braden, I’ve just realized that there is one more thing we need to remember about when using this approach. These tickets can often be cross-cell, so to see the correct numbers in YTD Spent and Period Spent columns in SprintCraft, we need to check the budgets on the main page instead of the cell-specific ones.
@jill Let’s just use CoreContributor . The other one is an older label we used, mostly about a year ago. We can even remove it if it’s confusing, I think.
Cool. I’ve removed the CoreCommitterContribution label from those tickets and replaced it with CoreContributor, which removed the old label from the list of existing tags.
, I’d just add that: