Hi Robert,
Robert Osfield wrote:
>
> My experiences were from nearly 10 years ago now.. But issues are the
> same. Fixing bugs is very much a social activity, in as much as it's
> the fixing bugs almost always requires a two way dialogue between the
> people able to reproduce the bug and those engaged in try to fix it.
> Facilitating the two way dialogue is absolutely the most important
> part of any bug resolution scheme - which is why I've always focused
> on osg-users as the route for bug resolution.
>
I think using a ticket system as already providid by the trac enviornment you
are using for the project is the way one should go to make the project more
flexible and younger. Look, the osg project is not a small project anymore and
the community is continuosly growing. Using mailing lists only doesn't make all
the users happy. And I still think that this kind of support/community is
outdated. There exists a lot of capabilities to handle big projects well.
Forums, Tickets and Wikis are such systems. We are happy to have a Wiki and a
Forum now and ticket system would just make the whole project more flexible and
better supported than now.
It could even reduce your workload, because users could assigned tickets to
themself and help other users without your intronvention. I understand that it
is hard to give away a control to more dezentralized way, however for a such
big project as osg it is the way to go in the future, I think. Come on, you
will still stay the big boss/president of the osg community ;)
Users/Developers/Contributors could register on the trac system with their own
usernames. Then whenever a new ticket or feature request is posted somebody who
thinks he is able to manage the bug, could assign the current ticket to
himself. Peoples visiting the ticket system are able then to trace the bug
resolution process and could see who is currently responsible for writing a
solution.
Even more as we have discussed in another thread ("Ideas for osg 3.0") ticket
system/trac environment could be setted up in a hierarchical way, so that there
will be a hierarchy of contributors/maintainers of the project. When we split
up osg to main core and node kit suites, there could be categories in the
ticket system handling only about the node kits and the maintainer responsible
for his node kit will do the managing work.
I think this is the way we have to go, instead of managing bugs on a wiki page.
Wiki pages would produce more work because of persistent mirroring of real osg
state on the wiki page.
Best regards,
art
------------------
Read this topic online here:
http://osgforum.tevs.eu/viewtopic.php?p=5264#5264
_______________________________________________
osg-users mailing list
[email protected]
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org