Difference between revisions of "BugSquad/Meetings/Minutes/2008-12-17"

From Sugar Labs
Jump to navigation Jump to search
Line 46: Line 46:
 
* Action items:
 
* Action items:
 
** #ACTION: marcopg to look at the upstream/downstream interaction fedora+GNOME
 
** #ACTION: marcopg to look at the upstream/downstream interaction fedora+GNOME
** #ACTION: mungwell to look at the upstream/downstream interaction ubuntu+GNOME
+
** #ACTION: mungwell to look at the upstream/downstream interaction ubuntu+GNOME (launchpad)
 
** #ACTION: erikos clean up wiki with today's info
 
** #ACTION: erikos clean up wiki with today's info
 
** #ACTION: erikos work on trac with marcopg
 
** #ACTION: erikos work on trac with marcopg

Revision as of 15:57, 17 December 2008


  • Meetings: when/if
    • schedule weekly triage meetings (especially to get people started, but things should be setup so that triaging happens async, because it needs to be a continuous)
    • at #sugar-meeting
  • Sprints: when/if
    • after releases
    • at #sugar-meeting
  • Do we need a dedicated mailing list?
    • No, we mostly have announcements and use tags if that is not the case, questions like (I was triaging bug #567 but didn't know what to do.)
    • sugar-devel - [bugsquad] and [bugsquad][announce]
    • "you can always triage at any time, and if you'd like to schedule your own sugar triage sprint, please do and announce it $here! if you're new and want help getting started but can't make a sprint, ask $here_2."
    • irc questions at #sugar
  • Create a list of concrete tasks we expect the BugSquad to do regularly
    • solicit distributions for testing of new releases
    • maintain the BugSquad wiki pages (especially with policies like "we use #sugar for discussion, tag your iaep posts this way")
    • add components, tags, milestones
    • triage tickets
    • provide feedback on how to improve bug advocacy on a ticket, when requested. ("How could I have written this bug report better / which developers should I ping on it"?)
  • Triage Policy:
    • Who is responsible for setting priorities and milestones?
      • the bug gets in
      • bug squad make the bug nice (a well-written bug report, a suggestion on the next step to push it to developers for fixing - who to talk to, etc.), assign to maintainer
      • maintainer assign a milestone
      • the dev does fix it :)
    • What needs to be happen to mark a ticket as fixed?
      • downstream takes the patch and puts it into their version and verifies and tests downstream, as needed
  • Action items:
    • #ACTION: marcopg to look at the upstream/downstream interaction fedora+GNOME
    • #ACTION: mungwell to look at the upstream/downstream interaction ubuntu+GNOME (launchpad)
    • #ACTION: erikos clean up wiki with today's info
    • #ACTION: erikos work on trac with marcopg