[Commotion-dev] Commotion's Community Governance Guidelines

[Ben West]

I agree with Michael this is a great start.  Also, am I correct that the
governance guidelines, mission, and goals are not yet on the wiki itself?

Besides adding more detail about mission and goals, I think this would be
good publish on the wiki sooner than later, to help Commotion better
identify itself (both to 'insiders' and 'outsiders') as a project based on
participation.  Likewise, perhaps add a conspicuous link to the governance
guidelines to the bug reporting form, in case a casual bug reporter would
like to become more involved?

Presumably, these guidelines would also help establish the process one goes
through in transitioning from 'outsider' to 'insider.'

On Mon, Nov 5, 2012 at 2:39 PM, Seamus Tuohy <s2e at opentechinstitute.org>wrote:

> Hello All,
>
> We have been working on the following draft of Commotion's Community
> Governance Guidelines. The first is a proposal for the overarching
> Commotion project guidelines. The second is a proposed individual
> project guideline for code submission and review. Now that we have a
> rough sketch of what we think we should include we would like to see
> what the active community wants added, removed, reworded, etc.
>
>
>
> Commotion Community Governance Guidelines
>
>   * The Commotion project is an open source, free software toolkit. The
>     community welcomes all contributions and conversations that help the
>     project grow and improve in accordance with its mission.
>   * Commotion’s Mission and Goals are guided by the active developers
>     and community stakeholders who contribute to the project community.
>     Active developers of Commotion projects will guide the development
>     of their individual project.
>   * The Commotion project team encourages communities to customize the
>     software to better meet local needs. We request that all
>     customizations be contributed or communicated back to the Commotion
>     community so that improvements can be reused without undue
>     duplication of effort.
>   * Work on Commotion should do no harm to existing projects. Projects
>     that implement new code that breaks the existing functionality of
>     other Commotion projects should work with the community of the
>     existing project in order to provide support for the existing
>     functions.
>
>   * New members may contribute to existing Commotion projects by
>     collaborating with active developers. Each Commotion subproject will
>     maintain an active version-controlled code repository. Guidelines
>     for contribution will be managed by each project’s active
>     developers, and will be posted on each project’s development page.
>
>
> Commotion Project Governance Guidelines
>
> To contribute to the (___________) project’s code repository you must
> post contributions to the development list for review. When the
> community has reviewed them you will be asked to submit a request to
> submit code so that the community can add your code to the project. At
> the point when repository administrators believe that you have a strong
> grasp of your contributed code’s effect on the rest of the code base,
> and that your intentions are to further the goals of the project with
> all of your contributions, you may be granted access to submit code
> directly to the code base without review. Malicious or damaging code
> that is submitted will cause those privileges to be revoked immediately.
>
>
>
> Thanks,
> Seamus 2e
> _______________________________________________
> Commotion-dev mailing list
> Commotion-dev at lists.chambana.net
> http://lists.chambana.net/mailman/listinfo/commotion-dev
>



-- 
Ben West
http://gowasabi.net
ben at gowasabi.net
314-246-9434
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.chambana.net/pipermail/commotion-dev/attachments/20121206/8b790606/attachment.html>