Following on from our recent
TWikiSummit in Rome, we didn't discuss the thorny subject of 'roles'. So I'm going to stick my head above the parapet, and see who shoots.
The Past

A bit of history. Back when TWiki was being created, the project was organised around a
CoreTeam. This team worked by allocating specific 'roles' to each individual in the team, and that person then took ownership of all aspects of that particular role. At one point the core team was up to 9 members, and was the powerhouse that created TWiki, at least up to Athens release. Core team members would provide leadership, recruiting contributors from outside the team, and so focus the efforts in the project. I can't comment on how well this worked (I have heard very different opinions from team members) as I wasn't involved at the time.
Over time several of the original members of the core team drifted off, or just scaled down their activities, until much of the work on TWiki was being done by people
outside the core team. Some core team members failed to provide leadership, or even fulfill their roles. Some simply abdicated. In addition, some people (me, basically) don't believe in fixed long-term role assignments in OSS projects. The core team has become less and less relevant as time went on.
The Present
As of the time of writing, the
CoreTeam still has significant influence, as it has a private mailing list and private web, and enough participants that if they work together, they could kill any initiative from outside the team. Several members are still very active, but the fact that they are in the core team is frankly a bit irrelevant, as people
outside the team are at least as active. This was clearly evidenced by the attendance at the recent Rome summit.
There
are some fixed roles that
have to exist, because if those roles are not clearly defined there is potential for FUD. The present
SecurityTeam is effective, and there needs to be a defined set of webmasters for maintaining TWiki.org and develop.twiki.org. But outside of these few specific roles, the reality is that teams form and dissolve dynamically - and often spontaneously - as the demands on the project shift. Project processes, such as the release process, reflect that. If we need to give someone specific authority - such as the
ReleaseManagerRole - we do it as a
community. This increases the authority of the individual, as they have a public mandate.
A potential contributor landing on Planet TWiki.org needs to be able to understand how the project works. Right now, they are given the message that the
CoreTeam is where it's at. But when they contact these people, or look at their recent contributions, they can be forgiven for thinking that the project is on its knees. They need to be given the impression of a dynamic and active community, not of a hidebound group of crusty elders who only wake up for lunch (sorry,
CoreTeam, I'm being deliberately cruel to make a point. I know you all wake up for dinner as well

)
The Future

I was really energised by the TWiki Summit in Rome, when I saw that we all realise that the TWiki project is bigger than any individual, or group of individuals. Decisions need to be taken in public, and not behind closed doors. Recognition needs to reflect actual contribution, and not just a name on a page. The doors need to be open to
everyone, no matter how large or how small their contribution.
Anyone (talented) should be able to walk up to the project and be able to feel that they are joining a community of peers.
So, to specifics. I started refactoring on some topics on Codev before I realised we need to clear the air about this. But what I would like to see is an FAQ page - nothing more, nothing less - that helps guide people to answers for the questions. No fancy TWiki Application, just a simple page (linked from the left bar, front page and
ReadMeFirst) that is easy to maintain, that points people towards the resources they need. For example:
| What do you want? |
Who should you talk to |
| I want to ask a newbie question |
Use TWikiIRC, or go to Support web and post a question there |
| I want professional support |
Employ a consultant, or buy CertifiedTWiki |
| I want to ask about (XXX)Plugin |
Ask in TWikiIRC, ask in Support web, or add your question to the (XXX)PluginDev page in Plugins web. As a last resort, contact the author by email. |
| I want to ask a question about the code |
... |
| I want to contribute to TWiki |
See HowCanIContribute |
| ... |
... |
- I would like to obsolete/remove from the radar/delete all the current CoreTeamRoles topics - there are dozens
- I would like to refactor other Codev pages to reflect this change in emphasis.
--
CrawfordCurrie - 22 Aug 2007
Discussion
I'm not sure i understand exactly what the refactoring is going to mean, i am not fully initiated at what is in codev yet (and will probably not be for years to come :). If you are proposing to dismantle coreteam, that'd be something i'd applaud. I'm all for egality and hierarchy-less structures. For me, TWiki is a meritocracy -> if i have seen your name on many contributions, your opinion is going to matter a lot to me. And those are the names i know and that for me are the 'core team', not the names that are listed as being part of the core team (although there is certainly an overlap).
The good thing about having such a core team, though, is that there is a set of people that have accepted more than average responsibility to take care of TWiki, to make sure the project stays on track.
--
KoenMartens - 22 Aug 2007
Good initiative. The "What do you want" starting points are a good way to structure visitor goals.
Instead of having roles we could emphasise 'tasks' ('jobs', 'projects') where people can contribute. For instance the Usability Expert Role should not be taken by one person. Multiple people can contribute to improve usability and user experience on multiple levels. That could lead to better visibility of things we envision as community.
--
ArthurClemens - 22 Aug 2007
Excellent idea; tasks should of course be
SMART (Specific, Measurable, Achievable, Realistic, Timeframed), and are much easier to track.
--
CrawfordCurrie - 22 Aug 2007