BugSquad/Meetings/Minutes/2008-12-17

• Agenda at http://sugarlabs.org/go/BugSquad/Meetings/Agendas/2008-12-17

• Logs: http://meeting.laptop.org/sugar-meeting.log.20081210_1206.html

• Do we agree on the mission?
  • http://sugarlabs.org/go/BugSquad/Mission (got accepted)

• What is needed in trac to start triaging?
  • add sucrose components
  • add milestones
  • base work flow on http://wiki.laptop.org/go/Trac_ticket_workflow
  • distribution field (where was the bug found)

• 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

3 maintainer assign a milestone 4 the dev does fix it :)

• • What needs to be happen to mark a ticket as fixed?

5, 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