Qt Project Web Open Governance

This article may require cleanup to meet the Qt Wiki's quality standards. Reason: Auto-imported from ExpressionEngine. Please improve this article if you can. Remove the {{cleanup}} tag and add this page to Updated pages list after it's clean.

The Qt Project Web Open Governance model

This document explains how the Qt Project Web Open Governance is organised, being meritocratic, consensus-based community.

Participation is easy. Membership is granted immediately. Anyone who shares that interest can join the community, participate in its decision making processes, and contribute to Qt’s development.

The model is subject to change, given needs and contributions from the Qt Project Web user community.

Background documents

• Qt Project Web Open Governance
• Qt Project Web Action plan
• Ideas for the Qt Project Web 2.0
• Summary of all the meetings
• Summary of the suggestions by February 3, 2013

Objectives

The two main objectives for running the Qt Project Web under open governance are:

• Put decision power in the hands of the community, making user participation and dections easy and transparant
• Helping making the Qt developer experience the best there is

There are several levels of involvement. Rights are added by number of activity points. This is handled automatically by the point system. You can be granted rights by recommendation, solving specific tasks and similar qualifying activities like organizing code.sprints, talks and so on. This figure shows the added rights as a result of activity points.

Open Governance Structure

Roles and activities

The point system explained

Role	Rights	Badge
Member	Can write wiki-pages, ask membership to groups and other fun and usable stuff :)	Lab rat
Editor	Can tag and add doc notes	Ant Farmer
Reviewer	Can remove existing tags	Hobby Entomologist
Initiater	Can request a group	Robot Herder
Forum moderator and admin	Can moderate and administer forum(s), remove spammers and maintain users group membership	Dinosaur Breeder, Gene Splicer
Chief Moderator	Helps make decisions if everyone disagree	To be determined
Web developer	Can make code contributions and improvements to the Qt Project Web system itself	To be determined
Sys.admin	Maintains the various services that make Qt Project Web	To be determined
Community Manager	Helps the whole system of contributors and systems work	To be determined
Project Manager	Runs the process of getting new features reviewed and tasks prioritized and executed	To be determined

Support

All participants in the community are encouraged to provide support for new Users. This support is an important way to grow the community. Those seeking help should recognize that all support activity within the Project is voluntary and is therefore provided as and when time allows.

A User requiring guaranteed response times or results should seek to purchase a support contract from other sources, but for those willing to engage with the Project on its own terms, and willing to help support other Users, the community support channels are ideal.

Initializing Open Governance

In most software projects there usually are more tasks to solve than manpower to solve those tasks. There are also "social" processes on how to point out whom to do those tasks, which rights contributors got and so on. There are also some process limitation regarding access, and which right you got to change or improve some parts of the web server product(s) in use. To clarify, there are three parallel processes:

1. Appoint contributors to different roles (bootstrapping, "applying" for more rights, running, withdraw from roles, restart).
2. Deployment of Open Governance of the Qt Project Web (we need to kick start it).
3. A process of suggesting improved or new features, prioritizing tasks and getting technically skilled persons to do those tasks. (Digia will provide web-developers and maintainers).

Decision making by lazy consensus

Decision making typically involves the following steps:

1. Proposal
2. Discussion
3. Decision, by
   1. Consensus
   2. Moderators, sys.admins or project management, given that consensus is not reached through discussion
   3. Chief Moderator, if Maintainers, sys.admins or project manager disagree and cannot reach consensus

Any community member can make a proposal for consideration by the community. In order to initiate a discussion about a new idea, they should send an email to the Qt Project Web maling list with the proposal and link to the wiki, request database or another easy way read about the suggestion. This will prompt a review by the user community. Other contributors might step up, willing to give a hand. Also, if necessary, a discussion of the idea might be done by key contributors and moderators.

Lazy consensus is a very important concept within the Qt Project. It is this process that allows a large group of people to efficiently reach consensus. A contributor with no objections to a proposal, don't need spending time stating their position, like an active vote. Contributors don't need to spend time reading such mails.

For lazy consensus to be effective, a reasonable amount of time should pass before assuming no objections. This requirement ensures that everyone is given enough time to read, digest and respond to the proposal. This time period should be chosen to be as inclusive as possible of all participants, regardless of their location and time commitments. Sometimes a week is sufficient, other times with bigger decisions, a month might be the best.

Prioritization of tasks and features (fixme: needs to be crystallized out)

Lazy approval: self organizing structure in which individuals choose roles and tasks for themselves and execute them. Responsibilities attach to people who do the work, rather than elected or selected officials.

Prioritization meetings:

1. Tasks and features added to the task list. This should include an work effort estimate and a priority rating.
2. The tasks will be reviewed periodically by moderators, sys.adms and web developers. This to selected tasks to work on with the resources at hand, including question to the Qt Project Web community to give a helping hand.
3. The status of tasks solved and features delivered will be presented
4. Loop to 1.

Feasibility study for larger work tasks

Feasibility study is about: Ideas are cheap, implementation is expensive; act accordingly.

This means that some ideas which seems to be simple, might got a side effects which needs much more effort to solve. Also, having a goal in sight, knowing the tasks ahead, is motivating when engaging in such activity. Being motivated is important for the Qt Project Web to work. It's also a way of priorities use of professional support, doing heavy lifting when that is needed.

The feasibility study should answer the following four questions:

1. What are the problems and benefits with the solution or technology use now?
2. What are other alternatives, and does those solve the problems or feature request?
3. What has to be done if we are replacing, or adding features to the current solution, and how long time does it take?
4. What are the consequences if we are keeping the current solution?

System access for development and maintenance

fixme: add the sufficient text for those new and clarified roles.

Conflict resolution (fixme: needs to be crystallized out)

Moderators are handling and moderating strong disagreements that can't be resolved. If that doesn't work, community manager will mediate. The basis for such mediation are based on community code of counduct .

dummy link

Licensing

Contributions to Qt Project Web can be used to improve the Qt framework itself. This spans from improved documentation to code and code examples.

Today everyone sings a Gitorious contribution license agreement, and all content are published under Creative Commons Attribution-ShareAlike 2.5 Generic. The plan is to clarify the license path 1H 2013, getting licenses aligned with the Qt Contributors License Agreement.