Error formatting macro: pagetree: java.lang.NullPointerException
Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version. Compare with Current  |   View Page History

Goals:

  • Improve quality and quantity of community contribution
    • Communicate ticket and patch expectations
    • Communicate where help is needed
    • Give visibility into what's happening in the process
    • Create dashboard showing ticket metrics/reports
  • Improve efficiency of existing workflow
    • Clarify existing workflow and update documents to describe it correctly
    • Create blessed reports (and dashboard) that everyone can use to see tickets in each state
    • Improve clarity of docs describing each activity, what report to use, actions to take, etc
    • Switch to JIRA workflow (see Clojure workflow (experimental) for Chas's prior work on this)
    • Maximize value of core Friday time by preparing places where we need help
 

This diagram represents an updated view of the process:

Notes about the various activities:

  • Triage
    • Who: Screeners
    • Report: Open tickets 
    • Goal: decide whether the bug or enhancement described in the ticket is actually a real bug or enhancement. 
      • For bugs, there should be some demonstration that the problem actually exists (output from a repl, test, etc). 
    • Actions:
      • Comment on ticket to ask for more information, better description, better demonstration of problem, etc
      • Close with Resolution=Decline, reasons: 
        • Not a bug: submitter misunderstood or misused a feature
        • Scope too big: feature may be better served by creating a page in the design wiki than in a ticket
        • Enhancement not wanted: enhancement is not something we want to do
        • Duplicate: of existing ticket
      • Set Approval=Triaged - problem is ok
        • If needed, adjust ticket to standards of triaged ticket below
  • Vetting
    • Who: Rich
    • Report: Triaged tickets
    • Goal: second check on whether the bug/enhancement is worth working on and decision of whether it's suitable for the next release.
    • Actions:
      • Close w Resolution=Declined - as above, ticket may not be something we want to address
      • Set Approval=Vetted - problem is good
  • Release scheduling
    • Who: Rich
    • Report: Vetted tickets
    • Goal: determine whether a ticket is in scope for next release or should be in backlog
    • Actions:
      • Set Fix Version to "Backlog" - don't want to fix it in the next release
      • Set Fix Version to current release
        • If does not have patch, will show up in "Needs Patch" report
        • If does have patch, will show up in "Screenable" report
  • Dev Patch
    • Who: contributors (anyone with signed CA)
    • Report: "Needs Patch" and "Incomplete" tickets
    • Goal: create a high quality ticket and patch for consideration (see sections below)
    • Actions: 
      • Edit ticket or update patch to address problems or gaps based on comments. 
  • Screening 
    • Who: Screeners
    • Reports: Screenable tickets (for new vetted tickets with patches), Incomplete tickets that have changed recently and may need re-review
    • Goal: verify that ticket and patch are ready for Rich to review. 
      • The quality bar is HIGH - the ticket and patch should be perfect
    • Actions:
      • Set Approval=Incomplete and add comment describing needed improvements
      • Set Approval=Screened - ticket and patch are perfect and Rich should review
  • Final screening
    • Who: Rich 
    • Report: Screened tickets
    • Goal: Rich blessing the change
    • Actions:
      • Set Approval=Incomplete - ticket or patch needs improvement 
      • Set Approval=OK - everything is good, ready to commit
  • Commit 
    • Who: Stu H (usually)
    • Report: OK tickets 
    • Goal: Final review of change and commit to Clojure source
    • Actions:
      • Set Approval=Accepted and commit patch to clojure src
  • Review
    • Who: Rich (primarily)
    • Report: Backlog tickets
    • Goal: See if backlogged tickets should be pulled into next release
    • Actions:
      • Set Fix Version from Backlog to current release 
      • (or don't to leave in Backlog)

Qualities of a triaged ticket

  • Ticket describes exactly one problem
  • Problem stated clearly
  • Demonstrate the problem as concisely as possible - via repl, test, etc

Qualities of a ticket ready for screening

  • (all properties of triaged ticket)
  • Proposed solution summarized (the end result of all comment or external discussion)
  • Name of patch for consideration - patch approach should match proposed solution
  • Alternate solutions considered and why rejected
  • Links to more commentary if external to the ticket

Qualities of a good patch

  • No extraneous changes (whitespace, unrelated mods, etc)
  • Docstrings should be adjusted if necessary
  • Test should be included if at all possible
Labels: