Marcus Lindblom wrote: >Ok. > >In general: > >Many, if not all, of the solutions listed seem nice. Why not convert >them to trac-tickets and put assign them to a milestone? > > I was holding off because some of the solutions are a departure from how things have been done in the past. They are more of a change in development workflow and philosophy. For those type of things I would want to reach consensus first and get everyone to agree and buy into the workflow. If we don't have everyone in agreement then we either lose people or we miss out on great ideas that we didn't take the time to discuss.
As far as the things that are tasks, making them tasks would be a great idea. Just please edit the wiki to have a link to the created task so we know it has been created. >All small issues that need fixing (experimental code etc) needs to be >documented. A number of wiki pages exists for this now >(PotentialContributions, ProjectIdeas, OngoingProjects, >FeaturesToPortFrom1to2). Shouldn't all these be centralized to one and >filled with content, so one can see what needs to be done? :) > > Yes. We could refactor those pages and make it more coherent. >OpenSG.org ought to have a big link to the trac site on the first page, >even if it is under construction. > >Roadmap: > >I think the roadmap is quite important, esp if we want to attract new >users who do not follow the mail-list. Trac has good help here, with >milestone and ticket support. I think it would be quite easy just to >summarize the big changes under each milestone, potentially with links >to wiki pages describing it in detail (see the Trac site for this, >they're pretty good). That way, each major task would have it's own >wiki-page, with tickets linked etc etc. Each milestone info would link >to the task-page so that one can see when a new feature is going to be >introduced. > > Agreed. IMHO the roadmap is the *the* most important development tool we can have. If we could get a coherent roadmap that everyone agrees to and create some additional demos, that would significantly increase the vitality of the project. But as you say, the roadmap is more then just the list of tasks. It is a list of "big" ticket items we want to do and priorities for them. I like the idea of linking to wiki pages about the features or refactorings that the roadmap relates to. For example in the 2.0 beta roadmap, having a link to a page about adding documentation would be great. >Immediate fix: Update Changes1To2 with a list on what you core-dev-guys >have in your head for that. (or put in the description of 2.0 >beta/release milsetones) > >Also, a milestone called OpenSG 3.0 (or something) for ideas that are in >there, but will have to wait quite a while? > > I like this idea. >Development: > >Other dev priorities from my point of view: > - Getting 1.8 out the door is good. > - Focus on 2.0 build. > - Getting everyone in on the 2.0 release game. > > Very much in agreement. I would like to push for some marketing priorities here as well. Namely demos of the existing 1.8 and 2.0 features. >Marketing & promotion: > >Gallery has expanded greatly. Very nice. Part of problem solved. >Dirk's writing on OpenSG features are impressive. :) >Get that OpenGL-link going asap. Also, investigate other places where >SG's are listed. Make sure we are visible everywhere! > > The big thing we need here is demos of capabilities. It doesn't matter if OpenSG has superb clustering or wonder shadowing or whatever. If there is no demo of it for us to promote, then it doesn't really exist in the minds of potential users. >(Ask OSG to put a link to us, if we link to them in return, to make sure >new users get to what they want without confusion?) > >Building: > >Generating vcprojs from the local file structure that kick of scons >should be pretty easy, if it's in the path. > >We should also provide a .bat-file for windows users that does something >like: > >call vcvars32.bat >if not exist scons.bat / python.exe echo failure!! >set INCLUDE / LIB / PATH = ... opensg/win32/supportlibs/ ... >devenv /useenv > >So it becomes dead-easy to get going. > > For the scons build we don't need this part. scons doesn't pick up the environment, so there is no need to call vcvars32.bat first. That said, I would be all for making win32 drop dead easy to use. >Examples: > >Screenshots / movies of each example on the website? Or in doxygen at >least. (A separate doxygen run for examples & high-level documentation >would probably make sense, to split that from API, which is more >difficult to keep nicely formatted.) > >(Is it possible to record from OpenSG? I don't think so, but there may >be experimental code for it. Ought to be fixed and perhaps even >automatically generated? .. start examples with a '--record' arg?) > > I have some code that will record change lists and allow them to be played back to create a video. I could contribute it if there is interest. >Documentation: > >I agree the proposed solutions. We just need to start getting people to >document. Someone needs to go through the docs and see what needs to be >done, then list this roughly on some 'documentation page', in some >priority order perhaps. After that, people will hopefully volounteer to >take charge over some part, documenting some and accepting >patches/delegating work to others. > > Great idea. Let's make it happen. >Loaders: > >Need to list which loaders ppl want somewhere, prioritize, ticketize and >assign to milestones. > > Agreed. I would like to see what it would take to port some OSG loaders over. >Conclusion: > >So, I think we are pretty good in agreement in general, but it may be >time to go down one step to details. We need to get some material in >there. Should we split the FutureOfOpenSG into pages for each issue, >detailing who is responsible, setting up tickets and linking to them >from there, etc etc? > > Yes. We also need to have discussions about the workflow and dev philosophy issues. >Also, we ought to start putting stuff into the >Ideas/Contributions/WhatToPort/Changes sites, so some we get some 'meat' >on the skeleton. That way, we can see where we are going. > >I'm quite excited about this. :) I think that if we get a structure down >on what should be done, others can pick up whatever threads they like. >We just need to lay out those threads and try to reach critical mass. > > Agreed. I am excited about this as well. :) -Allen >Cheers >/Marcus > >Allen Bierbaum wrote: > > >>Has anyone had time to look at this yet? >> >>Please help out, 30 minutes is really all it should take. :) >> >>Thanks, >>Allen >> >>Allen Bierbaum wrote: >> >> >> >>>As the discussions on the mailing list about the future of OpenSG >>>illustrated, people have many ideas about OpenSG's strengths, weaknesses >>>and future direction. This is great and it shows the community is very >>>active. I think it is important to followup on this discussion to allow >>>the community create a plan for how to move forward. >>> >>>Can everyone please review the page: >>>http://opensg.vrsource.org/trac/wiki/FutureOfOpenSg >>>and post your comments and feedback either on the page or the mailing list? >>> >>>If everyone takes 30 minutes to read through the page, think about the >>>issues, and contribute their ideas I think we can use it to plan the >>>future of OpenSG. It is my hope that this page can serve as a starting >>>point for developing a roadmap and coming to a consensus on where effort >>>can be most effectively spent over the next few months to improve OpenSG. >>> >>>Please take a look and contribute your ideas. >>> >>>Thanks, >>>Allen >>> >>>------------------------------------------------------------------------- >>>Take Surveys. Earn Cash. Influence the Future of IT >>>Join SourceForge.net's Techsay panel and you'll get the chance to share your >>>opinions on IT & business topics through brief surveys -- and earn cash >>>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>>_______________________________________________ >>>Opensg-users mailing list >>>[email protected] >>>https://lists.sourceforge.net/lists/listinfo/opensg-users >>> >>> >>> >>> >>> >>------------------------------------------------------------------------- >>Take Surveys. Earn Cash. Influence the Future of IT >>Join SourceForge.net's Techsay panel and you'll get the chance to share your >>opinions on IT & business topics through brief surveys -- and earn cash >>http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >>_______________________________________________ >>Opensg-users mailing list >>[email protected] >>https://lists.sourceforge.net/lists/listinfo/opensg-users >> >> > > >------------------------------------------------------------------------- >Take Surveys. Earn Cash. Influence the Future of IT >Join SourceForge.net's Techsay panel and you'll get the chance to share your >opinions on IT & business topics through brief surveys -- and earn cash >http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV >_______________________________________________ >Opensg-users mailing list >[email protected] >https://lists.sourceforge.net/lists/listinfo/opensg-users > > > ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Opensg-users mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/opensg-users
