1. "- information assets contained in the issues and resolution "
That would be nice but I have no idea what to do. You can search directly in the issue but that's a separate search from the doc site. I don't know of any way to tag these issues or serve these as a feed. We should probably make the issue queue more prominent on the doc web site. 2. "- 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." This would also be great and IMO even more relevant than the issue queue. This is tough with Google Groups though. It's tough with any mailing list/forum/wiki/web site integration. Manually adding links to threads and categorizing may work but probably not a ideal long term solution. We should display the Google Group feed (http://groups.google.com/group/simile-widgets/feeds) on the main simile website. Some thoughts, none of them ideal: - move to another system that better integrates online posts (forums) and mailing list. Something that supports open search, tagging, integrates with the wiki, etc... Of course, this would be A LOT of work (4K+ messages since Mar 2008) and potentially lose some niceties of Google Groups. Probably not realistic... :-) - add a special/hidden user to the Google Group whose inbox is regularly scanned and messages ingested in our doc site, which could then be parsed and searched with all the other pages. This would only work going forward though. - embed Google Groups and/or Mark Mail search (http://markmail.org/search/?q=simile#query:simile%20list%3Acom.googlegroups.simile-widgets+page:1+state:facets) into www.simile-widgets.org through an iframe. - create a custom search interface that is restricted to the Google Group/Mark Mail list, doc wiki, issue queue, etc..., something like using the site: qualifier through a standard Google Web search.) Any other ideas? - John Gmail wrote: > 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 -~----------~----~----~----~------~----~------~--~---
