Re: [wtp-dev] XSL Tools Release Plan page

[David Carver <dcarver@xxxxxxxxxxxxxxxx>]

Nitin, feel free to update the page to how you want it to look and to 
which other plans you want it to link too as well.   The XSL Tools plan 
is really focused on what is happening within th wst.xsl component, but 
it also needs to roll up into the overall WTP Source Editing plan.  It 
also only focuses on a particular milestone.  I'll generally have an 
idea that something is going to get done during WTP 3.2 milestone, but 
won't know which milestone until I start to plan for the actual 
milestone (usually just a day or two before the milestone starts).

The way the queries work, they automatically reflect what happens as the 
appropriate target milestones are set. I can add the plan key word if 
that helps, but an item is planned in wst.xsl if it has the target 
milestone set, and is in Assigned, New, or ReOpened status.  The queries 
only focus one milestone out.   So are updated just before the end of 
one milestone and the beginning of the next.

In many ways, they are implementing many of the Best Practices, proposed 
by the Architecture Council.  There are several groups include 
platform-ui that are starting to implement this way of working with 
bugzilla and managing the bug backlog.

http://wiki.eclipse.org/Architecture_Council/Bugzilla_Best_Practices

The reason there is no real owner at the moment is because of the Best 
Practice of only assigning an owner when the work is actually going to 
be done.   This lets the community know that anybody can work on it.   
The other option is to put the items into a triaged in-box, but leaving 
in the project in-box accomplishes the same thing.  Assigning it to a 
particular person when that person has a huge backlog of bugs can make 
it much more difficult and more likely that it won't get worked on 
anytime soon.  Plus the community thinks that because it is assigned, it 
is actually being worked on.

Anyways, that is the reason for there being "no true owner" assigned to 
a particular bug.  It allows anybody that has the time to work on the 
bug.   Plus it helps to eliminate knowledge silos that can occur if 
certain people are only responsible for certain parts of the system.

Dave


Nitin Dahyabhai wrote:
> David Carver wrote:
> > Just a note that I've updated the wst.xsl tools release plan with the 
> > list of bugs/enhancements on what has been planned/completed for WTP 
> > 3.2 so far.
> >
> > http://wiki.eclipse.org/XSL_Release_Plan
> >
> > Nitin please feel free to use this info or let me know what I need to 
> > add in order for these to show up in the official WTP release plan 
> > for Source Editing.
>
> As mentioned in Raghu's earlier note (7/16), we're using the standard 
> project plan format that draws items directly from Bugzilla. 
> http://www.eclipse.org/projects/project-plan.php?projectid=webtools.sourceediting 
> has pointed to our 3.2 queries for a while now, and a few items have 
> already been marked and even completed.  It is organized according to 
> the same broad themes as before and is in keeping with the overall WTP 
> plan document; simply mark bugs as plan items according to the 
> instructions written within each theme.  Not all bugs belong on the 
> plan, though, just the bigger items (meta-bugs/umbrella items would 
> for example, such as the W3C compliance bug itself).  I'm sure Raghu 
> is open to suggestions if you find the format lacking.
>
> Having more information in a wiki page is fine, particularly those 
> useful Bugzilla queries, but you'll have to keep it up to date.  And I 
> would prefer it link to the WTP Source Editing plan.
>
> I only have one requirement in addition to Raghu's: a bug is not to 
> appear as a Committed plan item (meaning it has a target milestone) 
> unless it is assigned to someone other than the inbox.  Over half of 
> the M2 targeted XSL bugs showing up on the wiki page's query link have 
> no real owner at this moment.  I know we all want to accomplish a 
> great deal with this release, but even those of us lucky enough to get 
> to work on WTP full time need to keep in mind that there's more to 
> what we do day-to-day than just churning out code.  Our newsgroups 
> could benefit from greater diligence from us all, and our builds are 
> still breaking far too often.
>
> Regards,
> ---
> Nitin Dahyabhai
> Eclipse WTP Source Editing
> IBM Rational
>
> _______________________________________________
> wtp-dev mailing list
> wtp-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/wtp-dev