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

From Sugar Labs
Jump to navigation Jump to search
(New page: * Do we agree on the mission? o http://sugarlabs.org/go/BugSquad/Mission * What is needed in trac to start triaging? o sucrose components, milestones, action...)
 
 
(16 intermediate revisions by 4 users not shown)
Line 1: Line 1:
−
    * Do we agree on the mission?
+
* Agenda at http://sugarlabs.org/go/BugSquad/Meetings/Agendas/2008-12-17
−
          o http://sugarlabs.org/go/BugSquad/Mission
 
  
−
    * What is needed in trac to start triaging?
+
* Logs: http://shell.sugarlabs.org/~erikos/bugsquad_17_12_2008.log
−
          o sucrose components, milestones, action needed field?
 
  
−
    * Meetings: when/if
 
−
          o triage meetings?
 
  
−
    * Sprints: when/if
+
* Do we agree on the mission?
−
          o maybe coordinated with downstream testing sprints?
+
** http://sugarlabs.org/go/BugSquad/Mission (got accepted)
  
−
    * Do we need a dedicated mailing list?
+
* What is needed in trac to start triaging?
−
          o what would be the emails that go to that list?
+
** add sucrose components
 +
** add milestones
 +
** base work flow on http://wiki.laptop.org/go/Trac_ticket_workflow
 +
** distribution field (where was the bug found)
  
−
    * Create a list of concrete tasks we expect the BugSquad to do regularly
+
* Meetings: when/if
−
          o How can we best help the poor developers?
+
** 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
  
−
    * Triage Policy:
+
* Sprints: when/if
−
          o Who is responsible for setting priorities and milestones?
+
** after releases
−
          o What needs to be happen to mark a ticket as fixed?
+
** at #sugar-meeting
 +
 
 +
* Do we need a dedicated mailing list?
 +
** No, we mostly have announcements and use tags for cases like: "I was triaging bug #567 but didn't know what to do?"
 +
** sugar-devel - [bugsquad] and [bugsquad][announce]
 +
** wiki note: "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 sugar-devel 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?
 +
*** not fully discussed the policy
 +
 
 +
* 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

Latest revision as of 19:16, 24 February 2010


  • 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 for cases like: "I was triaging bug #567 but didn't know what to do?"
    • sugar-devel - [bugsquad] and [bugsquad][announce]
    • wiki note: "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 sugar-devel 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?
      • not fully discussed the policy
  • 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
Retrieved from "https://wiki.sugarlabs.org/index.php?title=BugSquad/Meetings/Minutes/2008-12-17&oldid=48730"