Re: Quick sketch of the dev process
Looks good in general. I found it a little confusing how the info was split across the two pages (Home and All Proposals). How about changing the All Proposals page to encapsulate all proposal information in one table? It would look similar to the work-in-progress table on Home, but it could have a status column for draft, pending, approved, work-in-progress and implemented. Mark On 27/06/07, Eric Redmond [EMAIL PROTECTED] wrote: Not that this is really the thread for it, but +1 on trying out xwiki! Namely because Vincent is an insider (always nice to have) and I never really liked Confluence much anyway. Eric Not an XWiki Developer ;-) On 6/26/07, Vincent Massol [EMAIL PROTECTED] wrote: Hi Jason, Sounds very good to me. You're right that making things surface is a good thing. It requires more discipline but Maven being so successful and so many people relying on it now makes it a necessity I think to better control its evolution. Now all you need is a good wiki that allows you easier implementation/ follow up of that process... ;-) It would be real easy with xwiki to have a template for proposals and have a status combo box on each proposal that you could use to move a proposal between states. That would then allow you to query the proposals and list them on the dashboard page in the right category and do other nice things... (like, automatically send an email when a proposal in the draft state hasn't been touched for the past 6 months, or whatever comes to mind). -Vincent XWiki Developer (just to show that I'm probably biased... ;)) On Jun 26, 2007, at 1:02 AM, Jason van Zyl wrote: Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Eric Redmond http://www.sonatype.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
On 27 Jun 07, at 6:15 AM 27 Jun 07, Mark Hobson wrote: Looks good in general. I found it a little confusing how the info was split across the two pages (Home and All Proposals). How about changing the All Proposals page to encapsulate all proposal information in one table? It would look similar to the work-in-progress table on Home, but it could have a status column for draft, pending, approved, work-in-progress and implemented. You want to just try re-arranging it so we can see? Mark On 27/06/07, Eric Redmond [EMAIL PROTECTED] wrote: Not that this is really the thread for it, but +1 on trying out xwiki! Namely because Vincent is an insider (always nice to have) and I never really liked Confluence much anyway. Eric Not an XWiki Developer ;-) On 6/26/07, Vincent Massol [EMAIL PROTECTED] wrote: Hi Jason, Sounds very good to me. You're right that making things surface is a good thing. It requires more discipline but Maven being so successful and so many people relying on it now makes it a necessity I think to better control its evolution. Now all you need is a good wiki that allows you easier implementation/ follow up of that process... ;-) It would be real easy with xwiki to have a template for proposals and have a status combo box on each proposal that you could use to move a proposal between states. That would then allow you to query the proposals and list them on the dashboard page in the right category and do other nice things... (like, automatically send an email when a proposal in the draft state hasn't been touched for the past 6 months, or whatever comes to mind). -Vincent XWiki Developer (just to show that I'm probably biased... ;)) On Jun 26, 2007, at 1:02 AM, Jason van Zyl wrote: Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Eric Redmond http://www.sonatype.com - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
On 27/06/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 27 Jun 07, at 6:15 AM 27 Jun 07, Mark Hobson wrote: Looks good in general. I found it a little confusing how the info was split across the two pages (Home and All Proposals). How about changing the All Proposals page to encapsulate all proposal information in one table? It would look similar to the work-in-progress table on Home, but it could have a status column for draft, pending, approved, work-in-progress and implemented. You want to just try re-arranging it so we can see? How about something like that? http://docs.codehaus.org/display/MAVEN/Home http://docs.codehaus.org/display/MAVEN/All+Proposals Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
On 27 Jun 07, at 7:15 AM 27 Jun 07, Mark Hobson wrote: On 27/06/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 27 Jun 07, at 6:15 AM 27 Jun 07, Mark Hobson wrote: Looks good in general. I found it a little confusing how the info was split across the two pages (Home and All Proposals). How about changing the All Proposals page to encapsulate all proposal information in one table? It would look similar to the work-in-progress table on Home, but it could have a status column for draft, pending, approved, work-in-progress and implemented. You want to just try re-arranging it so we can see? How about something like that? http://docs.codehaus.org/display/MAVEN/Home http://docs.codehaus.org/display/MAVEN/All+Proposals I think I like having a listing of the work in progress on the main page so that you don't have to click to another page to see the work in progress. That said I like them all on one page, but I would like to extract the current ongoing work into the front page so that people can see right away what's being worked on without clicking somewhere else. Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
On 27/06/07, Jason van Zyl [EMAIL PROTECTED] wrote: I think I like having a listing of the work in progress on the main page so that you don't have to click to another page to see the work in progress. That said I like them all on one page, but I would like to extract the current ongoing work into the front page so that people can see right away what's being worked on without clicking somewhere else. Hmm, I'm no confluence expert - is that dynamic behaviour possible? W3C CSS have a similar page, which may be of interest: http://www.w3.org/Style/CSS/current-work Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
On 27 Jun 07, at 8:55 AM 27 Jun 07, Mark Hobson wrote: On 27/06/07, Jason van Zyl [EMAIL PROTECTED] wrote: I think I like having a listing of the work in progress on the main page so that you don't have to click to another page to see the work in progress. That said I like them all on one page, but I would like to extract the current ongoing work into the front page so that people can see right away what's being worked on without clicking somewhere else. Hmm, I'm no confluence expert - is that dynamic behaviour possible? Maybe we can tag them and show all the tags for things in progress. W3C CSS have a similar page, which may be of interest: http://www.w3.org/Style/CSS/current-work Mark - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Quick sketch of the dev process
I'm coming into the thread late so I see lots of updates already. I second the suggestion that having two states called Approved Proposal(s) is a little confusing. I think that the move to a Completed Proposals can be used to combine the Completed and Approved Proposals because there doesn't seem to be any actual work between Completed and the move besides the act of performing the move itself. Also, is there some need for a state between In Progress and Approved, where work started but has stopped for some reason? Something like Partial? I don't seem to have edit access in this space either. --Brian -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 7:02 PM To: Maven Developers List Subject: Quick sketch of the dev process Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - 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: Quick sketch of the dev process
On 6/26/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 25 Jun 07, at 7:11 PM 25 Jun 07, John Casey wrote: I like this approach, and I think it's just a slightly more detailed version of what some of us are already trying to do when we put together major new pieces for Maven. I agree with Eric that any API or behavioral change should probably follow this process, basically anything that could change what the user experiences. Yah, really just to surface the information. I know that there are only a few of us know where everything is because we look at it everyday but the casual contributor wouldn't have a chance. I think this really facilitates contribution. Someone who has a particular need can see if there is anything vaguely related to what he needs. agreed, so much of this material been beat around on irc and the back rooms of sleazy gin joints around the world...its good to get it all formally pulled into one area.. What would be the mechanism for ranking these in terms of priority or popularity or is that an concept we don't want to apply at this phase? My primary concern would be that given the wide variety of communication channels that maven folks operate under is this material becoming old or stale. Wiki's are notoriously easy to let languish. There has to be a concerted effort to make one place be the final resting place of all this sort of information. Its super easy to pay lipservice to this, 'oh, I'll just have the conversation on irc, or the mailing list and go back and update that wiki page later' and not follow through... of course, my stated primary concern there doesn't offer a better solution or alternative...just stating the obvious a bit anyway, +1, I like it :) -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
On 26 Jun 07, at 6:46 AM 26 Jun 07, Jesse McConnell wrote: On 6/26/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 25 Jun 07, at 7:11 PM 25 Jun 07, John Casey wrote: I like this approach, and I think it's just a slightly more detailed version of what some of us are already trying to do when we put together major new pieces for Maven. I agree with Eric that any API or behavioral change should probably follow this process, basically anything that could change what the user experiences. Yah, really just to surface the information. I know that there are only a few of us know where everything is because we look at it everyday but the casual contributor wouldn't have a chance. I think this really facilitates contribution. Someone who has a particular need can see if there is anything vaguely related to what he needs. agreed, so much of this material been beat around on irc and the back rooms of sleazy gin joints around the world...its good to get it all formally pulled into one area.. What would be the mechanism for ranking these in terms of priority or popularity or is that an concept we don't want to apply at this phase? My primary concern would be that given the wide variety of communication channels that maven folks operate under is this material becoming old or stale. Wiki's are notoriously easy to let languish. There has to be a concerted effort to make one place be the final resting place of all this sort of information. Its super easy to pay lipservice to this, 'oh, I'll just have the conversation on irc, or the mailing list and go back and update that wiki page later' and not follow through... You're right, it requires someone looking at it everyday and I don't mind doing that for the short term. If no one else picks up the process and starts using it then it's a flop. But given we have no way to show people what's actually going on in the project I think it's a decent first attempt and better then a kick in the pants. IMO, I think what's there on that one page would take someone 4 days of email list sifting to find. of course, my stated primary concern there doesn't offer a better solution or alternative...just stating the obvious a bit anyway, +1, I like it :) Cool, thanks. -- jesse mcconnell [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
RE: Quick sketch of the dev process
Looking over the current page, I see one mention of the Embedder. I'm unclear whether there are plans to release any embedder updates in the 2.0.* line. From the The Embedder for all client use in 2.1, I'm also unsure if the Embedder is to be released in the 2.1 line either. We're currently using an old Embedder release (v2.0.4) in the CruiseControl project, and I'm wondering if we should stop using it. Any suggestions? (I'd like to avoid hand rolling a non-release Embedder if possible). Thanks, Dan -Original Message- From: Jason van Zyl [mailto:[EMAIL PROTECTED] Sent: Monday, June 25, 2007 7:02 PM To: Maven Developers List Subject: Quick sketch of the dev process Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- -- This e-mail and any files transmitted with it may contain privileged or confidential information. It is solely for use by the individual for whom it is intended, even if addressed incorrectly. If you received this e-mail in error, please notify the sender; do not disclose, copy, distribute, or take any action in reliance on the contents of this information; and delete it from your system. Any other use of this e-mail is prohibited. Thank you for your compliance. -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
A few things: 1. Can I get edit access? My username is 'pschneider'. 2. Are there any thoughts re: how pages are parented? I noticed that only the 'Toolchains' proposal is parented by 'All Proposals'. Most of the rest seem to be under 'Maven 2.1 Design Documents'. It would be nice to see, at a glance, which version these proposals relate to, and an easy way to do that might be to categorize proposals with appropriate parent pages. I think as the list of proposals grows, it's going to be difficult to make sense of this page. This can be addressed later pretty easily I think. 3. I'm confused about where in svn new features get implemented. 'Where new development starts' (on http://docs.codehaus.org/display/MAVEN/Development+Process) says all new features/improvements go into the latest trunk revision. The 'Annotated Development Process' says to Create a feature/change branch and start working on your code. Which is is? Patrick On 6/25/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
On 26 Jun 07, at 1:20 PM 26 Jun 07, Patrick Schneider wrote: A few things: 1. Can I get edit access? My username is 'pschneider'. Sure. I'll find all the user names and add them to the group. 2. Are there any thoughts re: how pages are parented? I noticed that only the 'Toolchains' proposal is parented by 'All Proposals'. Most of the rest seem to be under 'Maven 2.1 Design Documents'. I am reshuffling pages around all the time so I've not used the lineage, but we start to now that things are gelling. It would be nice to see, at a glance, which version these proposals relate to, Good idea. How's this for a start: http://docs.codehaus.org/display/MAVEN/Home and an easy way to do that might be to categorize proposals with appropriate parent pages. I think as the list of proposals grows, it's going to be difficult to make sense of this page. This can be addressed later pretty easily I think. Sure, that sounds like a good idea. 3. I'm confused about where in svn new features get implemented. 'Where new development starts' (on http://docs.codehaus.org/display/MAVEN/Development+Process) says all new features/improvements go into the latest trunk revision. The 'Annotated Development Process' says to Create a feature/change branch and start working on your code. Which is is? Ok, so the new features start on trunk but the new feature is a branch of trunk. The point being feature additions don't destabilize the trunk. The series of branches associated with issues also provides a clear path of what happened, branches named with something like MNG-123-AndMaybeSomeQuickDescription make it easy to know what it is and to look up the issue. For dead simple fixes things can go into the trunk but anything requiring more then a few hours of work should go into a feature branch of trunk. When it's merged back into trunk, if it's possible it is then merged back into any version branches (like 2.0.x). Patrick On 6/25/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
On 6/26/07, Jason van Zyl [EMAIL PROTECTED] wrote: On 26 Jun 07, at 1:20 PM 26 Jun 07, Patrick Schneider wrote: A few things: 1. Can I get edit access? My username is 'pschneider'. Sure. I'll find all the user names and add them to the group. 2. Are there any thoughts re: how pages are parented? I noticed that only the 'Toolchains' proposal is parented by 'All Proposals'. Most of the rest seem to be under 'Maven 2.1 Design Documents'. I am reshuffling pages around all the time so I've not used the lineage, but we start to now that things are gelling. It would be nice to see, at a glance, which version these proposals relate to, Good idea. How's this for a start: http://docs.codehaus.org/display/MAVEN/Home and an easy way to do that might be to categorize proposals with appropriate parent pages. I think as the list of proposals grows, it's going to be difficult to make sense of this page. This can be addressed later pretty easily I think. Sure, that sounds like a good idea. 3. I'm confused about where in svn new features get implemented. 'Where new development starts' (on http://docs.codehaus.org/display/MAVEN/Development+Process) says all new features/improvements go into the latest trunk revision. The 'Annotated Development Process' says to Create a feature/change branch and start working on your code. Which is is? Ok, so the new features start on trunk but the new feature is a branch of trunk. The point being feature additions don't destabilize the trunk. The series of branches associated with issues also provides a clear path of what happened, branches named with something like MNG-123-AndMaybeSomeQuickDescription make it easy to know what it is and to look up the issue. For dead simple fixes things can go into the trunk but anything requiring more then a few hours of work should go into a feature branch of trunk. When it's merged back into trunk, if it's possible it is then merged back into any version branches (like 2.0.x). Gotcha -- this makes sense now. Guess I just needed it spelled out a little more explicitly ;o) Patrick On 6/25/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
The proposal looks generally ok to me. I'll try to follow it when working on Toolchains. I'm sure I'll have questions on the way. more regarding api changes below. On 6/26/07, John Casey [EMAIL PROTECTED] wrote: I like this approach, and I think it's just a slightly more detailed version of what some of us are already trying to do when we put together major new pieces for Maven. I agree with Eric that any API or behavioral change should probably follow this process, basically anything that could change what the user experiences. However, for me, it'd be nice if we could follow this documentation/ratification process with some enforcement and quality controls. For instance, I'd love to see something that would help us improve our test coverage (not just LoC, but functional coverage), and other pieces that would help keep us honest on API modifications. Clirr can do the latter, but I'm not sure there's a good tools for the former, as code-coverage doesn't tell the story of how much of a claimed feature actually works...that's more of an assessment of test quality as well as population. I'm not clear what is considered API within the codebase and what is the level of commitment for backward compatibility for various parts of the project. to get this in relation to my day job at netbeans.org.. there we have a clear line what is stable API that shall remain binary compatible as much as possible. Then there's friend' APIs that are less strict and a list of known users of the api is kept, limiting the change impact scope. It's known what packages are part of the API, the API Consumer/ API Provider contracts are clearly separated and the APis are created with future extensibilty in mind. Each change to APis is documented of course. however in maven codebase the lines are blurred to me. 1. plugins can basically use almost any component from the core, they can also provide implementations of components. what packages and components compose the official API towards the plugins and which are just internal to the core? 2. each component has an interface and a public default implementation. Are both part of the API contract or just the interface is? 3. what is the actual API we want to keep compatible? with what previous versions? 4. do we have a deprecation procedure? (like keep something for 1-2 releases deprecated and remove it afterwards?) Regards Milos This is definitely a step in the right direction, and should help us tame the release process a little more. Hmm, we should be writing all of this down for posterity...How We Tamed the Maven Development Process. That way, rather than being hypocrites for talking about idealistic dev processes that we don't follow, we can join the masses in our migration toward that ideal. ;-) Cheers, -john On 6/25/07, Eric Redmond [EMAIL PROTECTED] wrote: I kind of like the idea of this process applying to any API change - even if it's just a bug fix, not necessarily a feature request. It would also be nice to either have the Work articles under Work in Progress themselves contain contain the related JIRA issues (since there could be more than one, like ArchetypeNG) - either that or dictate that each proposal has one feature JIRA issue (that you can link others to). I don't know if this is already supposed to be the process, but it's clearly not being strongly adhered to. Something minor - I don't know if it was a graffle gaffe (ha) but it might get confusing having two steps named Approved Proposal. I would imagine one moves the draft to Approved before working on the project - which is kind of redundant since once it's approved it moves to work in progress. How about Drafts, Pending and Complete? Thanks; Eric On 6/25/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've
Re: Quick sketch of the dev process
On 26 Jun 07, at 2:05 PM 26 Jun 07, Patrick Schneider wrote: Ok, so the new features start on trunk but the new feature is a branch of trunk. The point being feature additions don't destabilize the trunk. The series of branches associated with issues also provides a clear path of what happened, branches named with something like MNG-123-AndMaybeSomeQuickDescription make it easy to know what it is and to look up the issue. For dead simple fixes things can go into the trunk but anything requiring more then a few hours of work should go into a feature branch of trunk. When it's merged back into trunk, if it's possible it is then merged back into any version branches (like 2.0.x). I put that into the document. Sorry for not being more clear. Gotcha -- this makes sense now. Guess I just needed it spelled out a little more explicitly ;o) Patrick On 6/25/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
Hi Jason, Sounds very good to me. You're right that making things surface is a good thing. It requires more discipline but Maven being so successful and so many people relying on it now makes it a necessity I think to better control its evolution. Now all you need is a good wiki that allows you easier implementation/ follow up of that process... ;-) It would be real easy with xwiki to have a template for proposals and have a status combo box on each proposal that you could use to move a proposal between states. That would then allow you to query the proposals and list them on the dashboard page in the right category and do other nice things... (like, automatically send an email when a proposal in the draft state hasn't been touched for the past 6 months, or whatever comes to mind). -Vincent XWiki Developer (just to show that I'm probably biased... ;)) On Jun 26, 2007, at 1:02 AM, Jason van Zyl wrote: Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
Not that this is really the thread for it, but +1 on trying out xwiki! Namely because Vincent is an insider (always nice to have) and I never really liked Confluence much anyway. Eric Not an XWiki Developer ;-) On 6/26/07, Vincent Massol [EMAIL PROTECTED] wrote: Hi Jason, Sounds very good to me. You're right that making things surface is a good thing. It requires more discipline but Maven being so successful and so many people relying on it now makes it a necessity I think to better control its evolution. Now all you need is a good wiki that allows you easier implementation/ follow up of that process... ;-) It would be real easy with xwiki to have a template for proposals and have a status combo box on each proposal that you could use to move a proposal between states. That would then allow you to query the proposals and list them on the dashboard page in the right category and do other nice things... (like, automatically send an email when a proposal in the draft state hasn't been touched for the past 6 months, or whatever comes to mind). -Vincent XWiki Developer (just to show that I'm probably biased... ;)) On Jun 26, 2007, at 1:02 AM, Jason van Zyl wrote: Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Eric Redmond http://www.sonatype.com
Quick sketch of the dev process
Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
Looks good. Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home Should all committers have write access to this area? - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
I kind of like the idea of this process applying to any API change - even if it's just a bug fix, not necessarily a feature request. It would also be nice to either have the Work articles under Work in Progress themselves contain contain the related JIRA issues (since there could be more than one, like ArchetypeNG) - either that or dictate that each proposal has one feature JIRA issue (that you can link others to). I don't know if this is already supposed to be the process, but it's clearly not being strongly adhered to. Something minor - I don't know if it was a graffle gaffe (ha) but it might get confusing having two steps named Approved Proposal. I would imagine one moves the draft to Approved before working on the project - which is kind of redundant since once it's approved it moves to work in progress. How about Drafts, Pending and Complete? Thanks; Eric On 6/25/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Eric Redmond http://www.sonatype.com
Re: Quick sketch of the dev process
I like this approach, and I think it's just a slightly more detailed version of what some of us are already trying to do when we put together major new pieces for Maven. I agree with Eric that any API or behavioral change should probably follow this process, basically anything that could change what the user experiences. However, for me, it'd be nice if we could follow this documentation/ratification process with some enforcement and quality controls. For instance, I'd love to see something that would help us improve our test coverage (not just LoC, but functional coverage), and other pieces that would help keep us honest on API modifications. Clirr can do the latter, but I'm not sure there's a good tools for the former, as code-coverage doesn't tell the story of how much of a claimed feature actually works...that's more of an assessment of test quality as well as population. This is definitely a step in the right direction, and should help us tame the release process a little more. Hmm, we should be writing all of this down for posterity...How We Tamed the Maven Development Process. That way, rather than being hypocrites for talking about idealistic dev processes that we don't follow, we can join the masses in our migration toward that ideal. ;-) Cheers, -john On 6/25/07, Eric Redmond [EMAIL PROTECTED] wrote: I kind of like the idea of this process applying to any API change - even if it's just a bug fix, not necessarily a feature request. It would also be nice to either have the Work articles under Work in Progress themselves contain contain the related JIRA issues (since there could be more than one, like ArchetypeNG) - either that or dictate that each proposal has one feature JIRA issue (that you can link others to). I don't know if this is already supposed to be the process, but it's clearly not being strongly adhered to. Something minor - I don't know if it was a graffle gaffe (ha) but it might get confusing having two steps named Approved Proposal. I would imagine one moves the draft to Approved before working on the project - which is kind of redundant since once it's approved it moves to work in progress. How about Drafts, Pending and Complete? Thanks; Eric On 6/25/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Eric Redmond http://www.sonatype.com -- John Casey --- Maven Developer (http://maven.apache.org) --- Blog: http://www.ejlife.net/blogs/buildchimp
Re: Quick sketch of the dev process
On 25 Jun 07, at 6:55 PM 25 Jun 07, Barrie Treloar wrote: Looks good. Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home Should all committers have write access to this area? Yes, if you don't then that's easily remedied. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
On 25 Jun 07, at 6:59 PM 25 Jun 07, Eric Redmond wrote: I kind of like the idea of this process applying to any API change - even if it's just a bug fix, not necessarily a feature request. It would also be nice to either have the Work articles under Work in Progress themselves contain contain the related JIRA issues (since there could be more than one, like ArchetypeNG) - either that or dictate that each proposal has one feature JIRA issue (that you can link others to). I don't know if this is already supposed to be the process, but it's clearly not being strongly adhered to. It would be good to have some easy way to grab the issues associated with each work in progress. Maybe an ad-hoc component to group them so that they don't have to be listed, we can just manually list them for now and eventually I see us finding ways for this information to surface with tools. But for now maintaining the dashboard and organizing everything there is still only a few minutes a day. Something minor - I don't know if it was a graffle gaffe (ha) but it might get confusing having two steps named Approved Proposal. I would imagine one moves the draft to Approved before working on the project - which is kind of redundant since once it's approved it moves to work in progress. Yup, you're right. How about Drafts, Pending and Complete? I''ll clean that up and I think i'll put the diagram sans the descriptions in the wiki in the left column and then annotate the diagram in the right column. Thanks; Eric On 6/25/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved. I've put some notes in the diagram and I figured we could start with a simple proposal to see how it works and iron the kinks as we go. This is experimental but I see it as the best way forward for getting a clear view of what's going on Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- Eric Redmond http://www.sonatype.com Thanks, Jason -- Jason van Zyl Founder and PMC Chair, Apache Maven jason at sonatype dot com -- - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Quick sketch of the dev process
On 25 Jun 07, at 7:11 PM 25 Jun 07, John Casey wrote: I like this approach, and I think it's just a slightly more detailed version of what some of us are already trying to do when we put together major new pieces for Maven. I agree with Eric that any API or behavioral change should probably follow this process, basically anything that could change what the user experiences. Yah, really just to surface the information. I know that there are only a few of us know where everything is because we look at it everyday but the casual contributor wouldn't have a chance. I think this really facilitates contribution. Someone who has a particular need can see if there is anything vaguely related to what he needs. The other place this can go is to have a place in the MAVENUSER space that is an analog for non-committers. Any committer who put together proposals for patches in the same way we did for adding/changing functionality would get my attention for first for sure. If we have a process that is visible we can make this accessible to contributors. However, for me, it'd be nice if we could follow this documentation/ratification process with some enforcement and quality controls. For instance, I'd love to see something that would help us improve our test coverage (not just LoC, but functional coverage), and other pieces that would help keep us honest on API modifications. Clirr can do the latter, but I'm not sure there's a good tools for the former, as code-coverage doesn't tell the story of how much of a claimed feature actually works...that's more of an assessment of test quality as well as population. We can certainly add the Clirr requirement and I'll add that to the requirements for deemed fit for completion. So right now the list is: - another committer to review - api inspection for compatibility I'm sure are many points that are implicit which we could make explicit. Like ITs being added, unit tests being included, javadoc ... and maybe even something like we do with the plugins where we have a standard usage document, so for new features this could be a requirement, how that meshes into the site. Many things are possible. This is just the start. This is definitely a step in the right direction, and should help us tame the release process a little more. Hmm, we should be writing all of this down for posterity...How We Tamed the Maven Development Process. That way, rather than being hypocrites for talking about idealistic dev processes that we don't follow, we can join the masses in our migration toward that ideal. ;-) Heh. Sure, I don't mind writing this up because it's my job currently during the day at two very large organizations struggling with the same issues. Cheers, -john On 6/25/07, Eric Redmond [EMAIL PROTECTED] wrote: I kind of like the idea of this process applying to any API change - even if it's just a bug fix, not necessarily a feature request. It would also be nice to either have the Work articles under Work in Progress themselves contain contain the related JIRA issues (since there could be more than one, like ArchetypeNG) - either that or dictate that each proposal has one feature JIRA issue (that you can link others to). I don't know if this is already supposed to be the process, but it's clearly not being strongly adhered to. Something minor - I don't know if it was a graffle gaffe (ha) but it might get confusing having two steps named Approved Proposal. I would imagine one moves the draft to Approved before working on the project - which is kind of redundant since once it's approved it moves to work in progress. How about Drafts, Pending and Complete? Thanks; Eric On 6/25/07, Jason van Zyl [EMAIL PROTECTED] wrote: Hi, As part of trying to make the whole process of making changes and adding new features transparent to everyone involved I've whipped up a little sketch for perusal: http://people.apache.org/~jvanzyl/DevProcess.png Basically it revolves around making sure things are documented in the Wiki and providing a clear record of the evolution of the project that anyone can follow at any point in time. So far from perfect but I think a good starting point and I would like to field feedback so I can improve it. It basically revolves around the dashboard where I've tried to collect all relevant information about the project: http://docs.codehaus.org/display/MAVEN/Home And process is based around making proposals that eventually will serve as the record of evolution of the project. The goal is not to have anything that's heavy, and that we might eventually be able to automate some data gathering but for the meantime it's not overly onerous and provides some visibility we have not yet had to date. The proposals are all here: http://docs.codehaus.org/display/MAVEN/All+Proposals And they basically move from draft - pending - approved.
