BugSquad/Meetings/Minutes/2008-12-17: Difference between revisions

Line 15:

* 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 (~~how do i triage~~ bug #3)

** 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?

1 the bug gets in

2 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

@@ Line 15: / Line 15: @@
 * 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 (how do i triage bug #3)
+** 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