I think it would be fantastic to copy everything from the legacy wiki to the current. I think that's the part of the legacy site that most often brings people back to it. We probably need to keep serving code from the legacy site to avoid breaking old exhibits, but once the doc is copied over I don't think anyone will need to explicit visit the legacy site.
mleden wrote: > 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 -~----------~----~----~----~------~----~------~--~---
