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


  • 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: Clojure/core
    • Report: Open tickets 
    • Goal: decide whether the bug or enhancement described in the ticket is actually a bug or enhancement. 
      • For bugs, there should be some demonstration that the problem actually exists (output from a repl, test, etc). 
    • Actions:
      • 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
      • 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:
      • Declined - as above, ticket may not be something we want to address
      • Backlog - problem is good but we don't want to fix it in the next release
      • Incomplete - problem is good, we want to fix it in the next release, but needs work
      • Vetted - problem is good, we want to fix it in the next release, have a patch, ready to screen
  • Dev Patch
    • Who: community
    • Report: Incomplete tickets
    • Goal: create a high quality ticket and patch for consideration (see sections below)
    • Actions: 
      • Vetted - patch is ready for consideration
  • Screening 
    • Who: Clojure/core
    • Report: Vetted tickets
    • 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:
      • Incomplete - ticket or patch needs improvement
      • Screened - ticket and patch are perfect and Rich should review
  • Final screening
    • Who: Rich 
    • Report: Screened tickets
    • Goal: Rich blessing the change
    • Actions:
      • Incomplete - ticket or patch needs improvement 
      • 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:
      • Accepted - patch committed
  • Review
    • Who: Rich (primarily)
    • Report: Backlog tickets
    • Goal: See if backlogged tickets should be pulled into next release
    • Actions:
      • Incomplete - ticket or patch needs improvement
      • Vetted - ready for screener review

Qualities of a triaged ticket

  • Ticket describes exactly one problem
  • Problem stated clearly, preferably with a brief snippet showing the problem if possible

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