Along similar lines, it would be great to see the "SIMILE online content" consolidated to the degree possible.
Right now, as I understand it, we have 3 main sources: 1. The "legacy site": http://simile.mit.edu 2. The "current site": http://www.simile-widgets.org 3. The "Google site": http://code.google.com/p/simile-widgets/ We've all seen lots of confusion on this message board about where to go for what. I find myself bouncing around between the three. At a minimum, it would be great to have any remaining content copied from the "legacy site" to the "current site". The "legacy site" URL could simply auto-forward to the "current site". I'm guessing the major benefit of using the "Google site" is for the development tools (source code control, issue tracking, etc). I presume that this might be a little trickier to consolidate (into the "current site"). As of right now, I can dedicate some time to any of the documentation/ housekeeping efforts (with a little direction). Just let me know directly how/if I can help. -Mark On Jun 4, 7:43 am, David Karger <[email protected]> wrote: > John, I'm reasonably certain we've defaulted to (1) because both (2) and > (3) require more substantial coordination and management, which we > haven't been able to offer from within the simile team (too little > manpower). I doubt (2) could work since it requires all contributors to > code a certain way. I'd love to see (3) but that requires some people > to step forward to join the doc team. > > John Callahan wrote: > > Before I went ahead and started making suggestions about if SIMILE needs > > a CMS vs a wiki site, I should have stepped back and asked what the > > overall documentation strategy is. I should have probably also asked if > > there were previous discussions about community building plans and how > > things have gone the past few years. Sorry about that. So, I started > > this new thread. :-) > > > What is the overall documentation strategy? > > > 1) complete community contributed documentation in a wiki/CMS, including > > api references, examples, and HowTo articles. This seems to be where we > > are now. > > > 2) dynamically derived documentation from the code itself (could use > > Natural Docs,http://www.naturaldocs.org/or similar, e.g., > >http://dev.openlayers.org/releases/OpenLayers-2.7/doc/apidocs/files/O...) > > This would require the authors to add much more info the code. > > Community would contribute examples and general articles. > > > 3) select a documentation team to create api reference and other > > FAQs/important info. (could use Sphinx,http://sphinx.pocoo.org/or > > similar, from restructured text, e.g., > >http://mapserver.org/documentation.html) Community would again > > contribute examples and general articles but under the guidelines of the > > doc team. > > > And I'm sure there are many others. Has this been previously discussed > > or decided upon? Any thoughts on best approaches? > > > - John --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "SIMILE Widgets" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/simile-widgets?hl=en -~----------~----~----~----~------~----~------~--~---
