SCons Bug Party

The SCons Bug Party is our semi-regular (bi-weekly?) session for examining and prioritizing open issues. When we started in March, 2008, we had no triaged issues and 430 untriaged issues (i.e., issues with a milestone of -unspecified-). Here's how we're doing today.

NOTE CHANGE OF TIME The next bug party will be on the #scons IRC channel (irc://irc.freenode.net/#scons), on Wednesday evening 19 November at 20h30 on the right coast (EST), 17h30 on the left coast (PST); that's after midnight in Europe (01h30 UTC, Tuesday morning), and 10h30 in Japan. It should last between sixty and ninety minutes. All are invited.

Agenda

As before, spreadsheets will be available to record comments prior to the bug party. Since this saves so much time, release team members are strongly encouraged to do this. Write access to the spreadsheets is available by following these instructions.

Specific agenda items:

s are left in the party:

t issues so there are none left over for next time; it would be really nice if we could deal with a goodly number of backlogged issues as well.

To look at the issues in advance, follow one of the agenda queries in the preceding list (i.e., not a spreadsheet link) and click on the ID of the first issue in the list. To look at each following issue, click on the "Next" link just below the colored bar containing the issue number. If you can do something to resolve the issue, don't wait for the bug party, go ahead and do it (remember to log in!).

Process

We'll examine each issue in succession. For each issue, we'll attempt to triage it by placing it in one of the categories below. The categories are either a resolution for the issue or a milestone when the issue will be worked. Resolved issues will be assigned to someone to close. For issues assigned a milestone, we'll also consider assigning a priority (P1 highest to P5 lowest) and a person to work the issue.

On the one hand, it's not considered evil to assign an issue to an earlier milestone and keep pushing it forward (there's the "at least they're considering it" effect), but on the other hand, if we're not going to get to it soon, it's better to label it as "future"; bug parties should regularly review "future" issues to prioritize them and pull them down into earlier milestones.

The 1.0 release is scheduled for early May. so only truly urgent issues or issues with known impact should be assigned to the 1.0 milestone. After that, the plan is to move expeditiously toward releasing 2.0, which is when many of the deprecated features will be removed. The interpretation of "expeditious" varies from a month to a year; something between those extremes is the most likely.

Categories

Categories in ALL CAPS are resolutions; the otCategories in ALL CAPS are resolutions; the others are milestones. No more issues are being accepted for 1.1. ctually a problem with SCons. An issue assigned to either of these should also be assigned to someone to write the comment that goes with the rejection.

WONTFIX
Issues that we won't fix. An issue assigned to this category should also be assigned to someone to write the comment that goes with the rejection.
-research-
Issues that still need research before being assigned to an actual milestone. An issue assigned to this category should also be assigned to someone to do the research and report back. Research assignments are usually small, and should be completed as quickly as possible, since there's usually a scheduling decision awaiting the result.
research
Issues that need further evaluation before being assigned to a milestone. The idea is that the research only needs a small amount of work (verifying that the issue has already been fixed, reproducing the problem, or determining what's affected by a fix) which can be done quickly. As such, the research should take precedence over just about everything else.
anytime

Issues that are not necessarily tied to the core release cycle, but should be worked as quickly as possible. This includes web page issues, small documentation issues (e.g., typos), long-running projects (refactorings, large new features, GSoC), and the like. Someone should be assigned to work the issue. (This milestone is sorted after the active milestone, so it's "what to do as soon as your current assignments are done.")

1.2
The second minor release after 1.0, scheduled for 22-Nov-2008. Someone should be assigned to work the issue.
1.3
The third minor release after 1.0, scheduled for 10-Jan-2009. Someone should be assigned to work the issue.
1.x

Issues that should be resolved during the 1.x release cycles, i.e., releases prior to 2.0. They are normally "promoted" into a release to schedule them, although if one is resolved early, it can be dropped in pretty much any time. Since the 1.x timeframe will be fairly short, most of these should have someone assigned to work them.

2.0
Issues that should be resolved as part of the move to 2.0. These are the backward-incompatible issues that can only be done at a major release point. Issues in this category include dropping support for Python versions before 2.2 and removing deprecated features. These issues should have someone assigned to work them.

he 2.x release cycles, i.e., a release prior to 3.0.

future

Issues that are far enough out that 3.x:: Issues that should be resolved during the 3.x release cycles, i.e., a release prior to 4.0.

it can't be decided where they should go. For an issue being moved to future, priority is its most important attribute, since that will influence how quickly it will be reconsidered; all issues relegated to the future milestone should explicitly specify a priority.

IRC Logs and Corresponding Spreadsheets

IRC logs of the previous bug parties, most recIRC logs of the previous bug parties, most recent first.

eadsheets.google.com/ccc?key=p3OolfevnannAYbMqCPfbOA&hl=en|recent issues]])

BugParty (last edited 2008-11-15 21:11:46 by GregNoel)