Difference between revisions of "BugSquad/Meetings/Minutes/2008-12-17"
Jump to navigation
Jump to search
m (moved Walter is a wanker 7/Meetings/Minutes/2008-12-17 to BugSquad/Meetings/Minutes/2008-12-17 over redirect: revert) |
|||
| (13 intermediate revisions by 4 users not shown) | |||
| Line 1: | Line 1: | ||
* Agenda at http://sugarlabs.org/go/BugSquad/Meetings/Agendas/2008-12-17 | * Agenda at http://sugarlabs.org/go/BugSquad/Meetings/Agendas/2008-12-17 | ||
| − | * Logs: http:// | + | * Logs: http://shell.sugarlabs.org/~erikos/bugsquad_17_12_2008.log |
| Line 14: | Line 14: | ||
* Meetings: when/if | * Meetings: when/if | ||
| − | ** triage meetings | + | ** 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 | * Sprints: when/if | ||
| − | ** | + | ** after releases |
| + | ** at #sugar-meeting | ||
* Do we need a dedicated mailing list? | * Do we need a dedicated mailing list? | ||
| − | ** what | + | ** 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 | * Create a list of concrete tasks we expect the BugSquad to do regularly | ||
** solicit distributions for testing of new releases | ** 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: | * Triage Policy: | ||
** Who is responsible for setting priorities and milestones? | ** 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? | ** 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 20:16, 24 February 2010
- 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 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
- Who is responsible for setting priorities and milestones?
- 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