I'm part of a fledging nonprofit called Barrel of Makers. We have a lot of people that want to help us out. However, they have very little time to give, an average of around 5 hours a week (might be 15 hrs some weeks, zero for the next 2). A lot of time they spend on Barrel of Makers is catching up with what has been done and what needs to be done. There is a lot of things going on and once and its not clear where people are needed, what has been done, what needs to be accomplished, or who has worked on what so far.
Basically, we need a management. However, even management has only 15 hours a week to give; its volunteer based! Additionally, the things we do can be very specialized. Often others don't even know whats involved! We can't really afford a single project manager to do what needs to be done yet either.
So we need to distribute the management among everyone, yet make it dead simple (or artist-friendly as I usually put it). Here's my idea:
Have a system where people can create tasks. Tasks can have the following information:
1) What needs to be done?
2) What skills are needed to do it?
3) What other tasks are dependent on this one?
4) What tasks is this task dependent on?
5) When does this need to be done by?
6) When can this task be started?
7) What has been done so far?
8) Who has worked on this?
9) Who is working on this?
10) Is this a project or part of a project?
Really basic. Only "what needs to be done?" is required!
Tasks have the following lifecycle:
- Pending: waiting for #6 above (or circle of trust issues).
- Open: waiting for someone to start the task.
- Assigned: At least one person is working on this.
- Completed: Someone said they completed this.
- Closed: The person that opened this bug or an administrator confirmed it was completed!
Tasks may only be deleted by administrators.
Tasks when filled out may have very details skill requirements, but likely not. As skills are defined, they are added to a skill list. Administrators or their assignees may arrange this into a hierarchy (such as Technology->Computers->Software->Ruby->Rails). The hierarchy has roots, but each node may also have parents-- it can be circular. Skills don't exist until they are used and are automatically hidden after not being used for 18 months. They also auto-tag tasks.
When a user logs in or signs up, they can add skills to their repertoire in the same way they assign needed skills to tasks (clicking through the hierarchy). If a new skill is added under a skill they say they have, they are asked if they are skilled in it the next time they go to their login page (after an admin flags it as ok).
Your home page has 5 sections:
1) Your skills. Only shows if there are new skills.
2) Tasks completed that need to be confirmed by you. Only shows if applicable.
3) Tasks you are working on. Only shows if applicable.
4) Open tasks you can work on in order of priority based on how many people can do that task and the priority of the task itself. Only shows if applicable.
5) Changes to Tasks and Projects you watch. Only shows if applicable. Works like an inbox/feed.
Section 2 is special. In addition to being able to take on a task, you may also change the skill requirements or your own. You may also choose to retain a skill but not get notified of tasks for it (c'mon I code all day long... I don't wanna code in my off time).
The following is on the menu that is always displayed:
1) Logins
2) Skills
3) Messages
4) Presence (available/busy/away/hidden)
5) Settings
Users can log on from either twitter, facebook, google, yahoo, or via openid. No need to roll our own authentication.
For authorization we use a circle of trust. New users may ask you to trust them (you can mark requests as spam). No one can ask administrators to trust them. In addition, you can choose to trust who they trust (called trust by association). You automatically trust anyone they do the same to. In this way, we can allow people to sign up and do whatever yet mark their actions as trusted or untrusted. People can choose not to let other people know they exist unless they are trusted. Yet this also allows new users to quickly join and be assimilated. Administrators are automatically trusted by everyone and everyone automatically trusts everyone an administrator trusts-- So administrators must be very careful who they trust and can delegate trust giving to others. Its easy to understand.
Implementation of who is trusted is relatively simple:
- Maintain groups of mutual (bidirectional) trust by association (maintained when a trust by association is added, may be circular) (Alpha Groups).
- For each Alpha Group, maintain a list of people that the alpha group users trust by association (Beta groups).
- For each Alpha Group, maintain a list of people that are merely trusted (Charlie group).
Asking if you trust a person is akin to asking if they are in any Alpha groups you trust, in any Beta groups you are a part of, and their associated Charlie groups.
Adding trust puts them in a Charlie group. Adding a trust by association puts them in an Beta group if the trust by association is not mutual. If it is mutual, it puts them in a new or existing Alpha group.
Removal of trust is very slow (and rare)! Addition of trust is fast (normal use case)! Verification of trust is fast!
No comments:
Post a Comment