Keeping STATUS Current (was Re: friday ha ha)
On 4/20/06, Don Brown [EMAIL PROTECTED] wrote: The bottom line is, IMO, the Struts project hasn't been as good as it could be at sharing our roadmap and vision with the user community. It is a personal goal of mine to improve this, and to see the continued success of both projects. One habit that Apache HTTPD practices, that we never learned at Jakarta, is the care and feeding of a STATUS file. Here's a link to the current HTTPD status file, which they post to the dev@ on a regular basis. * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS We do have a starter STATUS file in the SVN, * http://svn.apache.org/repos/asf/struts/STATUS.txt but if we want to get back to roadmap and communcation basics, I'd suggest this is the place to start. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping STATUS Current (was Re: friday ha ha)
I like the httpd one, clearly organized into sections that would be very helpful for guiding development. I think this is a great idea and vote we should adopt it too. Will shale, action, and tiles each have one, or will there be one for the whole project? Don Ted Husted wrote: On 4/20/06, Don Brown [EMAIL PROTECTED] wrote: The bottom line is, IMO, the Struts project hasn't been as good as it could be at sharing our roadmap and vision with the user community. It is a personal goal of mine to improve this, and to see the continued success of both projects. One habit that Apache HTTPD practices, that we never learned at Jakarta, is the care and feeding of a STATUS file. Here's a link to the current HTTPD status file, which they post to the dev@ on a regular basis. * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS We do have a starter STATUS file in the SVN, * http://svn.apache.org/repos/asf/struts/STATUS.txt but if we want to get back to roadmap and communcation basics, I'd suggest this is the place to start. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping STATUS Current (was Re: friday ha ha)
Looking at it further, this could all be done with JIRA how, which would probably be an easier interface to use and have the bonus of collecting comments and patches. Perhaps we could use the Priority value to signify the type of issue much like that status file does for httpd? The WebWork team goes so far as using JIRA tickets for simple task management (assigning tickets, notifying the start of work on a ticket, etc). Perhaps we should use that more, then have JIRA send a status summary to dev@ much like Bugzilla does today. They also are strict about assigning tickets to milestones, like we've started to do. This will help guide expectations on what will be in what release. Don Ted Husted wrote: On 4/20/06, Don Brown [EMAIL PROTECTED] wrote: The bottom line is, IMO, the Struts project hasn't been as good as it could be at sharing our roadmap and vision with the user community. It is a personal goal of mine to improve this, and to see the continued success of both projects. One habit that Apache HTTPD practices, that we never learned at Jakarta, is the care and feeding of a STATUS file. Here's a link to the current HTTPD status file, which they post to the dev@ on a regular basis. * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS We do have a starter STATUS file in the SVN, * http://svn.apache.org/repos/asf/struts/STATUS.txt but if we want to get back to roadmap and communcation basics, I'd suggest this is the place to start. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Keeping STATUS Current (was Re: friday ha ha)
Following Don's comments... with Java Web Parts, we have taken to using the Feature Requests feature at SourceForge for all work being done, regardless of whether it is actually a feature request or not... since you can open a ticket, assign it, prioritize, comment, etc., it gives us all one place to go to and see what tasks we plan to accomplish, and if anyone has assigned it to themselves to indicate they are actively working on it. Sounds like JIRA can serve the same purpose, so I like Don's suggestion. -- Frank W. Zammetti Founder and Chief Software Architect Omnytex Technologies http://www.omnytex.com AIM: fzammetti Yahoo: fzammetti MSN: [EMAIL PROTECTED] Java Web Parts - http://javawebparts.sourceforge.net Supplying the wheel, so you don't have to reinvent it! On Thu, April 20, 2006 2:30 pm, Don Brown said: Looking at it further, this could all be done with JIRA how, which would probably be an easier interface to use and have the bonus of collecting comments and patches. Perhaps we could use the Priority value to signify the type of issue much like that status file does for httpd? The WebWork team goes so far as using JIRA tickets for simple task management (assigning tickets, notifying the start of work on a ticket, etc). Perhaps we should use that more, then have JIRA send a status summary to dev@ much like Bugzilla does today. They also are strict about assigning tickets to milestones, like we've started to do. This will help guide expectations on what will be in what release. Don Ted Husted wrote: On 4/20/06, Don Brown [EMAIL PROTECTED] wrote: The bottom line is, IMO, the Struts project hasn't been as good as it could be at sharing our roadmap and vision with the user community. It is a personal goal of mine to improve this, and to see the continued success of both projects. One habit that Apache HTTPD practices, that we never learned at Jakarta, is the care and feeding of a STATUS file. Here's a link to the current HTTPD status file, which they post to the dev@ on a regular basis. * http://svn.apache.org/repos/asf/httpd/httpd/trunk/STATUS We do have a starter STATUS file in the SVN, * http://svn.apache.org/repos/asf/struts/STATUS.txt but if we want to get back to roadmap and communcation basics, I'd suggest this is the place to start. -Ted. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
