[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