Skip to content

Note about weighting and learning for package group

Steve Abrams requested to merge sabrams-master-patch-51694 into master

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:

  1. A sense of how quickly something might be delivered.
  2. A sense of whether or not something is too large or unknown and needs to be broken down.
  3. 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 @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. (this requirement has been removed pending identification of a new DRI for the handbook)
Edited by Steve Abrams

Merge request reports