<div dir="ltr">An interesting starting point here might just be some basic analytics to understand the scope of the work.<div><br><div>For example, having a list of all the tutorials sorted by traffic and marked by last edit date would help focus community efforts. Like, "hey, if you have a few hours to contribute to ROS, pick a high-traffic tutorial off this list, and run through it to make sure it's still solid."</div></div><div><br></div><div>If the raw traffic data for the wiki can be made public by OSRF, it's possible myself or someone else could take this on at some point.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 23 November 2014 at 13:36, Dirk Thomas <span dir="ltr"><<a href="mailto:dthomas@osrfoundation.org" target="_blank">dthomas@osrfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">While MoinMoin is not a great piece of technology the current wiki does provide us with several options:<div><br></div><div>* having a single page and mention in the content for which ROS versions it has been confirmed to work</div><div>* using the distro specific tabs to make minor adjustments for each ROS version</div><div>* generating subpages for each specific ROS version to completely separate the content</div><div><br></div><div>Generally I don't think that enforcing a specific approach for all pages makes sense.</div><div>The "best" choice basically comes down to:</div><div><br></div><div>* how much the content changes with each ROS version and</div><div>* personal preference of the people maintaining the content<br></div><div><br></div><div>Imo the major reason why the tutorials are not in a better shape is not a technological one.</div><div>It simply takes **a lot** of effort to maintain them - also because we have so many of them (which is a great thing).</div><div>And this maintenance work is done by a very small group of people.</div><div><br></div><div>While it makes sense to consider enhancements to the wiki macros etc. i don't think that they will ever on their own "solve" the problem.</div><div>We must encourage way more people to (write / ) maintain / review tutorials in order to spread the load and increase the coverage.</div><div>(May be a technological enhancement which enables gamification might help to motivate more people to contribute.)</div><span class="HOEnZb"><font color="#888888"><div><br></div><div>- Dirk</div></font></span><div><br></div><div>PS: Please also keep in mind that whatever change you propose must be implemented by someone.</div><div>And if that change requires more maintenance of the wiki page content we need to have people actually doing that.</div><div>So as good as it sounds to review each and every tutorial for a new ROS version I have a hard time believing that it is a realistic approach.</div></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Nov 23, 2014 at 7:55 AM, Paul Bouchier <span dir="ltr"><<a href="mailto:bouchier@classicnet.net" target="_blank">bouchier@classicnet.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
+1 for the idea of relegating old content to a history museum to
reduce maintenance. <br>
<br>
There can be other transitions in a package's life which change it
so dramatically that it's not worth maintaining the previous
content. However, the previous version is still there - in the
version history. Perhaps there could be a macro that let's an
author refer to a history tag and display a message something like
"The version of this page prior to <XYZ> his <here>,
where <XYZ> could be "catkin" or "groovy" or "API version 2.0"
or "new-sensor-version" etc. etc. This could work for tutorial pages
too.<span><font color="#888888"><br>
<br>
Paul Bouchier</font></span><div><div><br>
<br>
<div>On 11/22/2014 08:24 PM, Rud Merriam
wrote:<br>
</div>
</div></div><blockquote type="cite"><div><div>
<div>As someone new to ROS I find it very
frustrating to have the pre-catkin documentation in the Wiki. <br>
<br>
I would suggest you quickly move the pre-catkin material to a
separate Wiki for those still using those versions. Then begin a
rolling update system for new releases. You might keep three
release in the main Wiki while rolling previous releases into a
historical Wiki separate from the pre-catkin Wiki. That might
entail too much work, I realize. Maybe a diff/merge through a
version control system would work? I suggest that anyone working
with versions 3 years out of date probably can figure out the
documentation even if it is not perfect. <br>
<br>
<div><font color="#000080" face="Comic
Sans MS"><br>
- 73 - <br>
<b> Rud Merriam K5RUD<br>
</b> <i> <a href="http://mysticlakesoftware.com/" target="_blank">Mystic Lake
Software</a><br>
</i> <br>
<br>
</font></div>
<br>
</div>
<br>
<br>
<fieldset></fieldset>
<br>
</div></div><span><pre>_______________________________________________
ros-users mailing list
<a href="mailto:ros-users@lists.ros.org" target="_blank">ros-users@lists.ros.org</a>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a>
</pre>
</span></blockquote>
<br>
</div>
<br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org" target="_blank">ros-users@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br></div>
</div></div><br>_______________________________________________<br>
ros-users mailing list<br>
<a href="mailto:ros-users@lists.ros.org">ros-users@lists.ros.org</a><br>
<a href="http://lists.ros.org/mailman/listinfo/ros-users" target="_blank">http://lists.ros.org/mailman/listinfo/ros-users</a><br>
<br></blockquote></div><br></div>