note: I moved this discussion over to core for now... Allen Bierbaum wrote: > Dirk Reiners wrote: [snip] >>>> >>>> GV said: "I don't know why but this seems to be the major issue. Even >>>> with all the tools around we never seem to be able to utilize them to >>>> more than 5% of their potential." >>>> >>>> Communication is key for many of these other issues: roadmap, >>>> development, documentation, marketing, organization. >>>> >>>> How can we improve communication and coordination in the project? >>>> >>>> I think it probably boils down to making a more explicit effort at >>>> communicating and coming to an agreement on common things (roadmaps, >>>> direction, features, timing, etc) and making sure there is leadership in >>>> place to keep everyone coordinated. >>>> >> Toolwise I think Trac is very nice and supports everything we need. We >> just need to use it more consistently. I would really like for everybody >> who finds a bug to open a ticket. Same thing for everybody who starts >> working on something, open a ticket, add it to the milestone/release >> that you think it will go into, and keep track of your progress in the >> ticket. If you find anything that is broken or doesn't work the way it >> should, add a ticket that describes it and maybe what ideas you have to >> change it. Some of these tickets might get closed quickly, or postponed >> to later releases, but having a record of it in Trac, together with all >> the other outstanding issues will help us keep on track. Make tickets >> for little things, too, so that they can actually get done and closed >> quickly. >> >> My main problem (and that has been the problem since the very beginning, >> and that's the general problem that every Open Source project has), is >> that I have 0 power to make anybody do anything. Everything that happens >> is done by volunteers in time that they either need to take of their >> spare time or that they need to free from their bosses. In addition to >> that the people developing OpenSG are smart, which is both a boon and a >> bane. The boon is that they do some amazing things, the bane is that >> other people (and people closer to them geographically and higher up in >> the food chain) have demands on them that can change quickly and >> unpredictably and that cut into their time (that includes me). > > I agree with using Trac. The only thing I have a slight problem with is > the idea of asking people to start a ticket for new things and then > combining that into the roadmap. I think it needs to be done the other > way around (within reason) > > I have a pretty simple (and possibly naive) suggestion here. > > 1. We make a webpage for each release/iteration (maybe the roadmap page) > 2. We make a list of things we know we want to go in and things we would > like to see worked on (Dirk and other leaders start the page and others > contribute to it) > 3. We prioritize the list a bit and turn the tasks into tickets > 4. People pick the tickets they are willing/able to work on and put > their names with them. If they can, they try to give a time estimate, > something like "done before the end of October" or something else simple. > 5. When a task is done, cross it off the list. When the tasks are all > done the iteration is ready to go. > > This is a very simple workflow and has very little overhead. It would > allow people to put in features that they or their company need that > others may not, but it also allows people to know what is coming and to > work together to plan the needs. > > It also gives new contributors a place to look for things they can help > with and it gives users a place to look to see what is going to be > worked on next and for what iteration. > > So what do y'all think? Would this work for OpenSG and are the core > developers interested in trying things this way for a while? If it > doesn't work we can always change. >
Does anyone have comments on this proposed method of operation? What do y'all think about using a roadmap to list the things we all agree need to be done and then prioritizing them and picking out the things you are willing/able to do? I know I am an outsider and if you don't like this method of operation, that is fine. It is just that the question of how the development team plans future development and tracks progress is a very key question in any project and as a user I would like to know how the OpenSG core team plans to address this. I am sorry if I sound at all pushy in this, I have the same goal as you; to make OpenSG the best it possibly can be. -Allen ------------------------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 _______________________________________________ Opensg-core mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-core
