Hi Jan, On Sun, May 25, 2008 at 5:12 PM, Jan Ciger <[EMAIL PROTECTED]> wrote: >> So.... better search engines, better docs yep all helps, but in the >> end it's just tweaking things, it's not addressing the real problem - >> the projects over dependence on me carrying the ball for too many >> aspects of the project. > > Are you saying that you need few underlings to share the load? I think > that idea is a long overdue, Robert.
I first floated this idea at the Highland Gathering, and then in far more urgent form when Don departed. osg-crew was set up for this purpose of coordinating those supporting the project. Roles that have been taken on was Jose Luis Hidalgo stepped forward in the role as server admin, and put a huge amount of effort, with great support from his department in. Jose isn't so active on the lists these days though, and I believe that the server is now centrally managed by another admin, so this role is not quite as well defined as it was once was. Paul Martz and Bob Kuehne took on their quest to develop OSG documentation, the QuickStartGuide and Ref Guide books have come from this, as well as training course. However, this work hasn't has included coordination of the documentation on the wiki which is much needed. > I do not see why you should be the one maintaining mailing lists or the > web site. I could even imagine several trusted people having write > access to the repository - that would go a long way to clear the backlog > in submissions, letting you to focus on the design issues. Write access to repository is something I'm happy to see on a module basis, not full access. Eric Wing and Stephan Huber have write access to the XCode project for instance. I've exchanged a few emails with Paul Martz about the possibility of him getting write access to the OpenFlight plugin. General write access is not something I'm about to grant as the in review process I get to track what changes are being made and why. If I don't track these changes I start loose and understanding of the project. I also often modify submissions, or modify parts of the OSG in response to submissions. It's this process that keeps the coherency of the code base, it also keeps my head as coherent making it quicker and easier for me to do support because I have a good idea of exactly where the code is at. In terms of workload, if I was just the maintainer it'd be easy to keep on top of osg-submissions, so having lots of hands on this area isn't really required, it's all the other aspects to the project that currently fall on me to tackle because no one else takes stuff on. > You are not the first one having this problem as the project grows - > look up "Linus doesn't scale" for another well known instance (including > some of the solutions). Not the first, and not the last by any shot, it's common to all successful open and close source projects - how do you make things scale without breaking the essence of what makes the project successful in the first place. This isn't the first time I've made a call. Roles have to stick, or to be formally passed on when people need to move on or fallback when busy at work, but there has to be a steadiness to the role that means that I can hand over the reigns and not worry about stuff being handled, and also that the community knows who to go to for certain tasks. However, this commitment isn't easy to take on. Robert. _______________________________________________ osg-users mailing list osg-users@lists.openscenegraph.org http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
