michelle olson wrote: > Let me see if > I can re-state what you're proposing in a new picture of roles, followed > by the construct changes: > --------------------------- > | Members | > | ------------------------| > | | Project Leaders || > | | ---------------------|| > | | | OGB ||| > |-------------------------| > | Working Committee | > --------------------------
Not quite. I think we have +-------------------------+ | Participants | | +---------------------+ | | | Contributers | | | | +-----------------+ | | | | | Voting | | | | | | Contributers | | | | | +-----------------+ | | | | | | | | +-----------------+ | | | | | OGB? | | | | | +-----------------+ | | | +---------------------+ | +-------------------------+ Communities become Projects, and some Projects may become "Collective Groups". We have talked about Consolidation, SIG, Distribution, and User Groups in this context. We still are bashing around ideas for this structure, and are not at a point where we have closure. Where we almost have closure is on the roles people will have. The thing that was called Contributer would map to Contributer in the new world (duh :-), with potentially some set of attributes for the various Projects that the person was affiliated with. (The specific attributes are not yet enumerated here, though they will need to be before we can transition...) > > 1) Communities become Projects (removing the hierarchy) and in that > migration, pre-existing Community leaders become Project leaders with > commit rights to any repos that are set up. The thing that was called Member is now called "Voting Contributer". (I have no problem with reusing the name Member for this role) The thing that was called Core Contributer is now called Voting Contributer, with an assumption that there will be a way to assign attributes to individual Contributers that signify authority and trust and responsibility on a Project by Project basis. Some of those attributes presumably would signify commit rights, webpage editor rights, project leadership status etc for the various Projects that the person was affiliated with. > > 1.5) The new, bigger Project list that results from #1 above will be > divided by Type. The Type designations are still TBD. Yup, though see above for Collective Groups... > > 2) We continue to have Members (core contributors) and Project Leaders > (committers). Nope. There is no relationship between role and ability for anything other than governance (Voting Contributer -vs- the others) and for acknowledging contribution status (Participant -vs- the others). Nothing in the webapp should infer any rights or responsibilities about leadership, repo access, website editability etc from these three roles. That is what the attributes are for. > But, we create a new Working Committee to manage voting > rights and new project requests. Existing Community Facilitators and the > project-instantiation team become founders of that new Working Committee. Maybe. Or maybe we publish baseline membership and project creation guidelines and get out of the way. Or maybe we are saying the same thing :-) > > So, to request voting rights and new projects, you ask the Working > Committee. For access to web page editing and commit rights for existing > Projects, you mail the Project leaders on the associated lists. For > disputes, you go to OGB. I think so. > Am I getting any closer to understanding this? We all are, I hope :-) > Implementation Questions/Things to Consider: > -Does the os/communities# directory go away or is it redirected to > os/projects#? TBD > > -Is each os/community/communityname migrated to > os/project/communityname, so for example, os/community/documentation > becomes os/project/documentation? TBD > > -Are the Type designations (we've talked about Consolidation, SIG, > Distribution, and User Group) just labels with no impact on roles and > access, in order to improve on the current experience of navigating the > alphabetical list? I think so. > > -Or, do you mean to create new directories for the Types, such that we > have os/usergroups# and os/usergroup/SVOSUG? Good question. > > -Could the existing Emeritus Contributor role remain as-is (Jim C.s > question)? Since Contributer is for life, I'd assume this translates into a person with minimal attributes (i.e., you lose commit access, editorship, etc after a while, but you never lose the acknowledgment that you contributed something. > > -Could we remove the existing 'observer' and 'affiliate' features? Or maybe morph them into something useful? Observer is the way you subscribe to the project's aliases as a read-only watcher Affiliate may change the web navigation structure (noting that relationships do not have to map to directory structure or URL namespace...) -John
