Agir comme le corpus de prise de décision responsable pour gérer de façon cohérente les opérations de Meatball avec la MissionMeatball et les chartes des ProjetsMeatball?. Au-delà de tout cela, se concentrer pour agir à travers un ProcessusEquitable, et chaque fois que possible, se battre pour PasserPouvoir de manière raisonnable.
Mission Première: Suivre la MissionMeatball pour construire une communauté consistant à s'aider les uns les autres pour construire des communautés sous forme d'un HypermédiumCollaboratif.
Tous les contributeurs non exilés dans la CategoryHomePage (c'est à dire tous ceux utilisant un VraiNom) constituent les membres du conseil. (à savoir LeCollectif). Les comités individuels peuvent être plus restrictifs selon le ProcessusEquitable décidé pour gérer le problème. Comme toujours, efforcez-vous de PasserPouvoir sainement.
Pour le moment, il n'y a pas de comités.
Quand Meatball a été fondé en 2000, SunirShah et CliffordAdams se divisaient régulièrement les tâches. Cliff gérait les opérations (par ex. les serveurs et le code) et payait les coûts du site, et Sunir manageait la communauté. Cette séparation des problèmes était renforcée techniquement par le fait que Sunir n'avait pas les mots de passes d'administration. Par conséquent, chaque rôle était un EquilibreDeForce pour l'autre, parce que les problèmes techniques étaient négociés avec des problèmes sociaux. Plus tard, quand Cliff a commencé à partir, Sunir a pris des responsabilités supplémentaires qui ont constitué un ConflitIntérêt? entre le technique et le social, connu ici sous le terme RoiDieu. Cette situation est demeurée non résolue jusqu'aù moment où Sunir a pu trouver du temps dans les Grandes Ecoles, même parce qu'il pensait ce qui constituait du LogicielJuste?. Après avoir terminé ses tâches personnelles de la vie, Sunir a décidé de PasserPouvoir au ConseilMeatball mi-2006 afin de résoudre la situation.
Voir MeatballBoardBrainstorming pour la version pré-résumée de la page.
Mon idée originale d'un petit groupe de personnes représentant le Board était une mauvaise ; la communauté semble avoir formé un consensus sur le fait que le Board devrait rester ouvert, ce qui je pense est une idée de première classe. J'ai provoqué beaucoup de discussions sur les rôles et le vote. C'est le mauvais ordre. En restant aligné avec la ProchaineEtapeEvidente? et Wiki:YouArentGonnaNeedIt, la bonne voie est d'identifier spécifiquement ce qui a besoin d'être fait, quels processus doivent être mis en place pour la production et puis quels rôles doivent être remplis pour agir. Peut-être que nous aurons besoin de vous sur ce point. Peut-être pas parce que VoterEstMal?. Ceci étant dit, j'ai inclus la suggestion d'Helmut de former des comités (GroupesDeTravail?). La plupart d'entre eux seront probablement des comités ouverts libres (peut-être avec un ScrutinConsensus?).
Jusqu'à ce que de tels comités et procesus puissent se former, ma responsabilité est de les décrire clairement, encourager de meilleurs processus pour les régler et encourager les autres à prendre des responsabilités pour ces processus. Dans la période de transition, j'aurai encore à faire le gros oeuvre, aussi je suis vraiment motivé pour DéléguerResponsabilité. En clair, chaque fois qu'une décision doit être prise, je vais l'écrire, décrire le processus et demander à LeCollectif comment il veut en prendre le contrôle.
Tout cela repose sur l'hypothèse que s'il était clair que ce qui devait être fait et si c'était suffisamment dirigé, les gens seraient bénévoles. Est-ce que je me trompe ? Idées. Ai-je résumé les choses correctement ? -- SunirShah
La majeure partie du temps, le GroupeConsensus est probablement plus facile que le ScrutinConsensus? ; on a seulement besoin du dernier en cas de dissenssion, en fait sur MeatballAntiSpam -- ChrisPurcell