User talk:Nlee/Task tracker requirements
- skill requirements for a task are perhaps a set of <skill, level> tuples. rather than a single tuple.
- tasks tend to accumulate notes and commentary. and so should have an associated wiki place.
- a very big value added not mentioned is being able to see what's going on. generate reports, etc.
- there are various olpc project things which one really wants a real database for. it might be a nifty extra benefit if this project was a prototype/foundation for blending database like things with the wiki.
- more mediawiki apis yay! Mchua
MitchellNCharity 17:01, 16 October 2007 (EDT)
Echo all that Mitchell said above, plus some more stuff to think about.
relationship to existing systems
Don't pay too much attention to this question, it's just my default starter. What is the relationship between this task tracker and the other task tracker(s) being used currently - most notably, git? It's not as simple as a code/not-code split, since code and content are super-closely related especially in things like games. Is it a parallel system?
leads vs volunteers
Volunteers should be able to post tasks, too. I actually don't see a distinction between project leads & volunteers. Project leads can just keep a tighter watch on the tickets tagged for their project - because what if a project lead is the only one that can admin tasks for a project and then they suddenly drop off the radar? (For instance, my recent "shit, getting internet is hard" stunt... how would that affect the projects and tasks I'm involved in with such a system?)
Taking a page from Content stamping, there does need to be a way to make it easy for people to create ways (how's that for a meta-full sentence?) of marking tasks as "important," "productive," or at least "you won't be wasting your time." Usernames would help tracking here. Taking another page, this time from del.icio.us, perhaps there could be a way for me to do a search like "show me all the tasks, due before Wednesday, with an 'university-chapter' tag (by anyone at all) that has also been tagged 'important' by Nikki (whose opinion I trust on which tasks are important, and who I consider my admin/supervisor-type person for this particular set of goals)."
You could then do stuff like replacing "Nikki" in the search above by a list of multiple names (I consider the admin group for project X to be Mitchell, Nikki, and Xavi...) or even by a group name you define in your personal account as shorthand for a list of multiple names (so instead of typing Nikki & Andy & Andy & Greg & ... you just type "Olin group," which you've preset to that list of names for your account).
Incidentally, this might be possible and not too onerous with semantic mediawiki, although I'm not sure how to easily access the "what actions have been taken by what user?" info.
In effect, instead of people declaring themselves admins of such and such a project, it's the volunteers themselves who decide who they'll consider admins (who is worth listening to regarding tasks on a particular project).
big design question here: what fields are required, what fields are optional but have a set format, and what fields are totally free-form? for an interesting pair of viewpoints on this google up the difference between the rss and atom specs - they're a good example of the kinds of issues that come up when you're trying to decide how loose or tight to make a spec.
- dependencies - need to be able to say that you can't do task B until task A is completed. this could be a simple as just writing words to that effect in the descript of task B, then linking to task A, and vice versa.
- how to avoid deadwood tasks? actually, sorting tasks is itself a task... although hopefully not too much time will be spent on that because that's the stuff bureaucracy and red tape is made of.
- this is awesome stuff, by the way. I love the way you're thinking about this.
Mchua 12:00, 18 October 2007 (EDT)