Bugzilla – Full Text Bug Listing
| Summary: | [pmi] Automatically create default project plan | ||
|---|---|---|---|
| Product: | Community | Reporter: | Konstantin Komissarchik <konstantin> |
| Component: | Project Management & Portal | Assignee: | Portal Bugzilla Dummy Inbox <portal-inbox> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | wayne.beaton |
| Version: | unspecified | ||
| Target Milestone: | 2014-Q2 | ||
| Hardware: | All | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | 432859 | ||
| Bug Blocks: | |||
|
Description
Konstantin Komissarchik
Another way to go is to drop the plan concept entirely and simply integrate display of Bugzilla entries related to the release (perhaps another tab). I have found it extremely helpful to maintain a link from the release page to the Bugzilla table report, from where interested parties can drill down further. For instance... here is the page for Sapphire 0.7.1 http://www.eclipse.org/sapphire/releases/0.7.1/ ... and here is the bugzilla query it links to... https://bugs.eclipse.org/bugs/report.cgi?x_axis_field=bug_status&y_axis_field=bug_severity&z_axis_field=&query_format=report-table&short_desc_type=allwordssubstr&short_desc=&classification=Technology&product=Sapphire&target_milestone=0.7.1&longdesc_type=allwordssubstr&longdesc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whiteboard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&emailtype1=substring&email1=&emailtype2=substring&email2=&bug_id_type=anyexact&bug_id=&votes=&chfieldfrom=&chfieldto=Now&chfieldvalue=&format=table&action=wrap&field0-0-0=noop&type0-0-0=noop&value0-0-0= ... it would be even better if there was a way to embed the query table into a page, but I haven't found an easy way to do this... Automating the inclusion of a bug list is relatively easy, so long as the version number provided in the release matches the version number in Bugzilla (not currently true for the Sapphire 8.0 release). I'm not convinced that a plan should be nothing more than a bug list. In some cases it will be a big, intimidating, meaningless bug list. I would expect that new bugs will be added over time; this no big deal, plans are expected to change over time. I believe that the themes are valuable. They at least have the potential to set a tone that invites the community to create bugs addressing particular items. They provide further meaning by grouping like things together. By working with a URL, we give projects flexibility to decide how to mix and match their bugs. Is this really that hard? - create a description - create a theme - add a Bugzilla link to the theme - click "save" - get coffee Most of the plan fields for a plan are optional. IMHO, some actual effort needs to go into planning. (In reply to Konstantin Komissarchik from comment #1) > ... and here is the bugzilla query it links to... That's something that is appropriate for a review. Or perhaps a status box. In fact, I had something like that in the PMI at one point. It's not, however, particularly open. It does nothing to invite people to participate in your project. It's more of a "this is how we're doing" sort of thing. (In reply to Wayne Beaton from comment #3) > It's not, however, particularly open. It does nothing to invite people to > participate in your project. It's more of a "this is how we're doing" sort > of thing. I should have added that it's valuable. It's just not planning. > provided in the release matches the version number in Bugzilla (not currently > true for the Sapphire 8.0 release). I fixed Sapphire 8 release record to drop the extra zero. > I'm not convinced that a plan should be nothing more than a bug list. In some > cases it will be a big, intimidating, meaningless bug list. That's why the report table is so useful. An interested party can quickly zero in on enhancements or see at a glance if the release is primarily focused on features or bug fixes. A plan document that tries to be more than a reference into Bugzilla is stale the moment it is written. > IMHO, some actual effort needs to go into planning. Clearly, but all the real planning is happening in Bugzilla and on mailing lists and forums, not in the plan document. > I believe that the themes are valuable. They at least have the potential > to set a tone that invites the community to create bugs addressing > particular items. Themes can be effectively communicated in the release description. Extra imposed structure does nothing to invite the community to participate. > That's something that is appropriate for a review. Or perhaps a status box. The idea of an explicit plan document and an explicit review document is stuck in the waterfall model way of thinking. One morphs into the other over the course of the release and the only difference between the two is the verb tense of the description and the number of finished items. In any case, my base suggestion here is to produce a default plan automatically, so that the only thing that needs to be entered is version number, date and description. If some projects find value in the current approach, that can be left as an option. (In reply to Konstantin Komissarchik from comment #5) > The idea of an explicit plan document and an explicit review document is > stuck in the waterfall model way of thinking. Planning is part of Agile. The planning game is a fundamental pat of XP. The Eclipse Development Process bookending release cycles with a plan and review is derived from the early work of Erich Gamma and John Weigand, which I believe is pretty universally regarded as "agile". Release cycles have plans. Even in the Agile world. The key word here that distinguishes this sort of planning from waterfall is, I think, "cycles". We're not looking for a book here. A plan is not a specification or a design. We're looking for vague themes describing the intended focus of the release. It's something that adopters can use to base their own plans on. Themes are along the lines of "Improve usability", "Prepare for Internationalization", "Refactor the core". These are pretty significant sorts of ideas that can't be relayed with bunch of bugzilla records. Maybe they could be relayed in the text of the description, but having them as themes lets you provide context around groupings of bugs, which I contend is valuable. FWIW, a theme of "Fix bugs" is reasonable, if that's what you mean (no fair just providing a blanket theme that means "do whatever we want"). More pragmatically... project plans are a requirement of the Eclipse Development Process. If you want to change that, then we need to address that to the Architecture Council. The current structure of project plans is a requirement from the board; if we want to change that, we need to take that up with the committer reps. Could you reference where the board has specified that the plans must have themes? I just did a search of EDP and did not find any hits on word "theme" and plans were only referenced in abstract sense. I don't see why we must force all projects to one way of thinking. If some find explicit themes valuable, that's fine, but that does not imply that the rest aren't planning or effectively communicating with the community. (In reply to Konstantin Komissarchik from comment #7) > Could you reference where the board has specified that the plans must have > themes? I just did a search of EDP and did not find any hits on word "theme" > and plans were only referenced in abstract sense. http://wiki.eclipse.org/Development_Resources/Project_Plan/XML with discussion on Bug 215301 Thanks for the reference. The primary concerns I see discussed in Bug 215301 is the need for standardized plan format and a lot of emphasis on planning via Bugzilla. I believe it would be consistent with stated goals and the board's resolution if the default project plan had say two themes: "Bug Fixes" and "Enhancements" with corresponding bugzilla queries. Then if some projects find value in customizing themes and entering more adhoc information into the plan document, they can. After some thought, I think we should do this. But how about this... we add two fields. On the plan page, we add a "Targeted Bugs" field that lists all bugs with a target version that matches the release version. On the review page, we add a "Fixed Bugs" field that lists all bugs with a target version that matches the release version and are marked [RESOLVED|CLOSED]/FIXED I may be able to do some regular expression cleverness to make the version matches a little fuzzy/forgiving. I think that the "Issues" tab solves this. More here: https://www.eclipse.org/projects/handbook/#pmi-release-issues |