[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [wtp-dev] XSL Tools Release Plan page
|
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
