Note about weighting and learning for package group
Discussion
How should we account for "learning time" when weighting issues and estimating milestones? This is inspired by a GraphQL issue I took on. Because it was my first GraphQL issue, it took me longer than if I had already gone through a GraphQL MR or two.
I know there are arguments for and against weighting accounting for experience level, but I think for the purpose of our group, weighting seems to give us three things:
- A sense of how quickly something might be delivered.
- A sense of whether or not something is too large or unknown and needs to be broken down.
- A way to look at a set of issues and decide if they can all be delivered in a milestone or not.
Based on those reasons, I think 1 and 3 tend to argue that accounting for the "learning time" in the weight would be helpful.
I appreciate your thoughts and discussion!
Author Checklist
-
Provided a concise title for the MR -
Added a description to this MR explaining the reasons for the proposed change, per say-why-not-just-what -
Assign this change to the correct DRI - If the DRI for the page/s being updated isn’t immediately clear, then assign it to one of the people listed in the "Maintained by" section in on the page being edited.
- If your manager does not have merge rights, please ask someone to merge it AFTER it has been approved by your manager in #mr-buddies.
-
If the changes relate to any part of the project other than updates to content and/or data files please make sure to ping(this requirement has been removed pending identification of a new DRI for the handbook)@gl-static-site-editor
in a comment for a review and merge. For example changes to.gitlab-ci.yml
, JavaScript/CSS/Ruby code or the layout files.
Edited by Steve Abrams