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.
The next bug party will be on the #scons IRC channel (irc://irc.freenode.net/#scons), on 24 May, 2011 at 20h00 on the right coast (EDT), 17h00 on the left coast (PDT), and after midnight in most of Europe; for specific locations, check the timezone information here. It should last between sixty and ninety minutes. All are invited.
Responsibilities of Release Team Members
Release team members are expected to subscribe to this wiki page (using the "Subscribe" link above) so that they will be automatically notified of any changes. Not all changes will be reported in the mailing list, but it is expected that "non-routine" changes will be.
Approximately 4 days before the bug party, a Google spreadsheet will be published corresponding to the the agenda below. Release team members are expected to record their comments and (initial) appraisal in the spreadsheet. Write access to the spreadsheets is available by following these instructions. (If you can't access the instructions page, please email firstname.lastname@example.org and ask to be added to the ReleaseGroup. It's open to all, as is the bug party itself, but this keeps the noise down a bit.)
If there is no quorum of comments six hours before the bug party, the meeting is automatically rescheduled one week later. In this context, a quorum is that "most" of the issues have three or more significant comments attached to them. (The definition of "most" is flexible, as the number of issues varies so widely. If there's disagreement about whether "most" of the issues have a quorum, the bug party will be held according to the original schedule.) Issues that lack a quorum will be bypassed at the bug party.
People who comment on the issues will be expected to attend the meeting, unless they specifically send mail to the contrary. People who comment but do not attend must make sure that their comments are particularly understandable or the comments will be ignored.
The meeting is called and moved to the next week if there's no quorum by five minutes past the start time. In this context, a quorum is at least three team members who commented on the issues.
Specific agenda items:
- Triage issues. As a rule of thumb, issues are expected to be resolved in two or three minutes on average. If the discussion of an issue goes past five minutes, it should be moved into email and the issue bypassed until the next meeting. This agenda item is suspended with about fifteen minutes left in the expected meeting time to allow for the remaining agenda items.
- Discuss current status of recent and near-future releases (whether checkpoint, candidate, or public):
- Schedule, including any adjustments
- What's expected to be in future releases
- Whether we should do any retriage for current or future releases
- Other related topics
- Confirm next week's meeting time: Default candidate time is in two weeks on Tuesday at 17h00 US/Pacific for sixty to ninety minutes.
To look at the issues in advance, go to the corresponding issues list and click on the ID of the first issue in the list. To look at each successive 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!).
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.
We are moving (expeditiously?) toward a 2.0 release, when many of the currently deprecated features will be removed. There's already too much work in 1.x to complete all the issues planned, so unless a fix is truly urgent or a problem is small and has a well-understood impact, most issues should be assigned to a 2.x release or later.
Categories in ALL CAPS are resolutions; the others are milestones. No more issues are being accepted for 1.3 or 1.x.
- INVALID or WORKSFORME
- Issues that aren't actually 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.
- 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.
- 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. There's usually a scheduling decision awaiting the result, so the research should take precedence over just about everything else.
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.")
- The first minor release after 2.0, scheduled for October 2010. Someone should be assigned to work the issue.
- The second minor release after 2.0. Someone should be assigned to work the issue.
- The third minor release after 2.0. Someone should be assigned to work the issue.
Issues that should be resolved during the 2.x release cycles, i.e., a release prior to 3.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.
- Issues that should be resolved as part of the move to 3.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.4 and removing deprecated features.
Issues that should be resolved during the 3.x release cycles, i.e., a release prior to 4.0.
Issues that are far enough out that 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 recent first.
/IrcLog2009-11-17 Release planning for 1.3, no bug triage.
/IrcLog2008-04-12, including interruptions
[test edit, ignore]