Activities trac

A quick and dirty hack of a prototype Activity management system, an alternative to the current cluttered Activities page which nobody seems to want to maintain because... well, it's hard, and the page is not a very good tool for doing so. See the mailing list thread for context.

To-do

Want to help? Contact Mchua (or set an instance up yourself somewhere, which is perfectly all right as well.)

• Make the activities trac work with git
• Install the plugins listed at the bottom of http://trac-hacks.org
• Copy a few sample activities and users in

Done

• Install Trac Mchua

Introduction

I've heard that strawman artifact-examples to play with helps groups move forward (also known as "I can has working code?") so here's an experimental attempt to do so.

(the below is culled from an IRC convo with Bernie)

what would you think of something like http://trac-hacks.org/ but for .xo and .xol files only? (In other words, Activity and library bundle development, compartmentalized and separated from "core" Sugar code, user docs, etc. - a developers' center.) Let's call this xo-get.org for now, in homage to Chris Hager's awesome Activity.

The current structure for Activity development, as best as I can tell, is "code in git, (sometimes) tickets in trac, (sometimes) user/teacher docs on the wiki, (rarely) devel documentation on the wiki." This is scattered, unclear, involves lots of manual work... it doesn't seem to be functioning well, or to be a system that people enjoy using.

xo-get.org would have "code in git, (always) tickets in trac, (always) devel documentation in trac, (hopefully) user docs on the wiki." The goal would be to make life as easy for Activity developers as humanly possible. Some helpful features...

• more-easily-sortable "Activities" page - "show me all bundles that work with Sugar's current version," etc.
• for both people (users) and code (things like the xo-get activity), it will hopefully be easier to find/pull/script/contribute-to things in a more structured resource.
• the grassroots-people structure might find it easier to tweak this tech-tool structure for Activity development facilitation, since the manual work will never end (when something's marked "please test!" someone still has to go find testers, someone has to test it...) Tools that are pleasant to tweak tend to become tools that are pleasant to use, which tend to become tools that are used.

Implementation

Right now this is a lot of hypothetical "wouldn't this be nice" talk, so to turn this into action... I'm going to try to set up a strawman/demo trac-hacks like installation late tonight after I get back from 1cc. Advance warning: it will be slow as molasses because my personal webspace is on a shared server. I'll fill it with a few sample uploads of Activity code to give people an idea of what could be done with it.

So here's what I'll ask this list to hold me to: within 24 hours, I will holler out the URL to the strawman on this list so people can play around and decide whether to tweak/keep/toss, or what might work better. If the general consensus is that this isn't useful but we have a good discussion on why it isn't and what might be, I'll be ecstatic, because we'll be moving forward and getting more concreteness into the mix.