Hi All, I'm also willing to volunteer. Assisted by Stefano; I completed moving the legacy issues for Exhibit and Timeline to Google code after Easter. So there are two sources to include in the strategy and planning: - information assets contained in the issues and resolution - following the excellent technical support demonstrates that "key threads" often play an important part in resolution. Hence a categorization and listing of these threads would enhance productivity.
BTW, is there another source of documentation for the API's? I searched for documentation on the HTML table importer but could find only the code in the API source. Is there a documentation reference as well? I would invest some time to move, collect, or document the legacy material and help develop the future references. Put me into the team planning. Regards, Gary Gabriel John Callahan wrote: > That is exactly where all of this is headed. I'm willing to volunteer > (and help coordinate) as well. Maybe we can get a handful of people > together, develop a strategy, and start populating with content. > > From what I know... > > All documentation should be at http://www.simile-widgets.org > Examples, HowTo articles, links to resources also at > http://www.simile-widgets.org > Code apis should be at http://api.simile-widgets.org/ > Email list/forum at http://groups.google.com/group/simile-widgets?hl=en > SVN repository at http://simile-widgets.googlecode.com/svn/ > Issue tracking at http://code.google.com/p/simile-widgets/issues/list > > > IMO, It's be great to remove docs/resources form the old legacy site and > remove some of the components (wiki, download) from the Google site. > > - John > > > > > 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 -~----------~----~----~----~------~----~------~--~---
