Difference between revisions of "Talk:U.s.oo.o/Charter"

Latest revision as of 04:10, 17 October 2007

Preamble

Agreement-seeking culture

We desire to create an agreement-seeking culture. That is, we endeavor to make plans and reach decisions based on achieving wide-spread agreement. Agreement-seeking is not the same as consensus, as consensus tries for universal agreement; elusive, if not impossible, to achieve.

Agreement-seeking as a central principle is also different than majority rule. While voting can play a constructive role as an advisory means of expression of preference, binding procedures of any kind can under-emphasize and even undermine the critical role of discussion and deliberation in the shaping of plans. Voting is considered assertively consultative, not binding. Elections of individuals to fill roles within the organization, on the other hand, are binding.

For agreements to be meaningful, it is important that those with a stake in the outcome be participants in determining the course of action. So, for instance, it's a matter of common sense that those with technical expertise should be intimately involved in technical decision-making.

Further, given that User Community Volunteers (UCV) is focusing on developing services for non-technical users, it is also important that end-user interests be represented in the process of creating services.

Filling a role is a matter of taking responsibility, not imposing one's will.

We believe in making progress through giving clear responsibilities to individuals. Taking responsibility for something is not the same as ownership, rather stewardship for an area, activity, or issue. Taking responsibility can also require, at times, acting as a driver. It should not be assumed that stewards and drivers typically operate by imposing their own decisions. Driving is primarily a matter of attending to a project with a goal, and taking steps to ensure the goal is reached (or, occasionally, redefining or setting aside the effort). Stewards typically solicit input and proposals, enable active participation, and facilitate discussion. In some (but not all) cases, the steward will also be an active content contributor to the matter at hand.

The steward has a responsibility to consider multiple points of view and to try to reach widespread agreement. If there is disagreement, she or he should use methods to shed more light on the issue, e.g., by taking it to a wider group such as a mailing list or forum.

However, it is also the stewards's responsibility to see that a decision is made, and he or she has the right in the end to make that call if in his or her judgment that's the right course of action.

Legitimate decisions are made with reference to the the vision, mission, and values of the organization.

All decisions, but particularly ones about which there is disagreement, should not be made arbitrarily but should be in keeping with the vision, mission, and values of the organization. Decisions gain legitimacy when they can be linked to an underlying set of core beliefs widely shared by the participants.

Some of our core values are:

• personal integrity and accountability
• individual initiative
• respect
• responsible risk taking
• openness and transparency
• teamwork
• sustainability

Applying these to forum behavior we might say, "Rude and personal comments on forums are disrespectful and not acceptable. Constructive criticism on the other hand is warmly encouraged."

Project proposals need to win community buy-in before implementation

A good proposal or project plan not only sets out what is to be done and why, but also how, i.e., it addresses execution issues and seeks buy-in from those who will be implementing it. This is always important, but especially so when the proposer's plan requires significant resources not under his or her direct control, which will typically be the case.

Governance principles are more important than ownership

In working through situations of disagreement, it is better to focus on applying governance principles rather than determining who has ultimate authority, as over-reliance on the latter can short-circuit opportunities to rely on and expand the use of healthy, open processes.

Based on OSAF Governance Principles

Charter of the OpenOffice.org User Community Volunteers

Scope of this charter and interpretation

This charter relates to the affairs of OpenOffice.org User Community Volunteers, hereinafter called the group ( "the group" ) having charge of the website users.services.openoffice.org (or any successor to that site) ("the site") and its sub-domains.

The primary purpose of the site is to provide information and support relevant to the end users of the OpenOffice.org software(or any software derived from or designed to work with).

The group may adopt any other purpose, which in its judgment supports the primary purpose of the site or the performance of the group's functions.

Members of the group are referred to in this charter as volunteers.

The charter shall be deemed to be enabling and not to impose liability.

Particular provisions are for the sake of clarification or extension and not intended to reduce the fullness of the group's power and authority.

Any notice relating to the site may be given to a person by email.

Functions of the group

The primary purpose of the group is to govern the site. The group may

• govern, regulate and supervise membership, content, management and administration of the site
• administer its own affairs as fully as those of the site
• appoint officers ( "officers" ) to perform any functions
• enlist any assistance it sees fit
• delegate any power or function
• conduct polls
• amend or replace this charter.

Volunteers may hold discussions using any vehicle or vehicles they choose.

Designated Roles within 'the site'

User

a User is any person who enters or uses the web site in any way, even if that person only visited the home page of the web site.

Guest

A Guest is a user that is not logged onto the site, which means that they may not be registered. A guest may view and search site content that does not require special roles to view, such as a moderator only forum. If a guest is allowed to add content, the content will be approved by a moderator before it is accepted.

Member

A Member is a User who has successfully completed the site registration process⁽²⁾ at the web site. A Member can also post or modify the information content of the site, within the content rules of the site.

Designated Roles within 'the group'

Volunteer

A Volunteer must be a Member of the site.

A Member of the site must request to become a member of Volunteer.

Volunteers are collectively referred to as the OpenOffice.org User Community Volunteers (OUCV). There is no cap on the size of the OUCV.

The Member must apply to become a Volunteer though the registration process⁽²⁾, and, if successful, will be elected to Volunteer status within the UCV. For a Member to be successful, some evidence of sustained commitment will normally be required; for example, numerous postings and wiki contributions, or a number of material articles over a six month period. An equivalent track record in an associated community will normally be acceptable, for example, one of the other active OpenOffice.org or Linux related forums.

he Member must apply to become a Volunteer though the registration process⁽²⁾, and, if successful, will be elected to Volunteer status within the UCV. For a Member to be successful, some evidence of sustained commitment will normally be required; for example, numerous postings and wiki contributions, or a number of material articles over a six month period. An equivalent track record in an associated community will normally be acceptable, for example, one of the other active OpenOffice.org or Linux related forums.

The OUCV is intended to comprise the community of the 'active' Members within the site, Volunteers may, therefore, revert back to a normal Member.

• A Volunteer may resign from Volunteer status.
• A six month period with no activity at the site will automatically propose removal of Volunteer status. ( Reversion to simple Member status at the site Drew 15:28, 14 October 2007 (CEST))
• Any Volunteer may propose the removal of Volunteer status for any other Volunteer. Justification must be included with the request. For example, repeated abuse or disregard of the site, the membership, or standing instructions endorsed by the OUCV.

The removal of Volunteer status is also controlled through the registration process⁽²⁾, and where this occurs the individual will revert to normal Member status. A Member can always reapply for Volunteer status.

Volunteers are regarded as trusted members of the site and therefore have available elevated privileges associated with such trust:

• Full voting privileges within the OUCV.
• Ability to upload images and attachments to the site.
• Ability to use HTML in posts; most forum packages allow HTML as an option, and the layout is easier than in BBcode-style mark-up languages.
• Ability to blog.
• Eligibility for site roles.

Site Roles available to Volunteers

The following site Roles are available to OUCV members. Notwithstanding this, the list of site roles and responsibilities may evolve over time under change control and endorsement through the OUCV voting process.

Site Administrator

Individuals that are willing to take on the responsibilities necessary to perform a due diligence in the following areas:

• Help maintain the security of the host system by:
  • Maintaining a good working relationship with designated network administration staff at Sun Microsystems, Hamburg Germany.
  • Maintain contact with the vendor's / supplier's information service for any applications run on the server.
  • Take agreed upon steps when a security announcement is made by the vendors / suppliers.
  • Follow agreed upon steps if a security breach of any application on the server is suspected. For example: notified by a board user that they suspect a problem.
  • Perform steps necessary to carry out agreed upon configuration control procedures on application level services running on the server. During modifications of the applications, application of patches, reconfigurations.
  • Follow agreed upon steps / actions to implement and maintain a disaster recovery plan ( e.g. off-site storage of backups, off-site storage of application modifications, included files and configuration settings).
• Support the Service Administrators and Content managers by performing the following tasks:
  • Create or apply modifications to the applications source or configuration files as needed.
  • Configure client communication settings for the service application.
  • Configure server settings for the service application.
    • Database indexing.
    • Database backups ( working with network admins ).
    • Install / configure support packages ( php libs, caching systems, etc ).

These individuals must also comply with all Standard Operating and Security Procedures defined by the hosting provider ( SUN Microsystems ), and to take whatever reasonable actions that the hosting provider requires of them in order to receive necessary host computer access privileges.

Service Administrator

Individuals that are willing to take on the responsibilities necessary to maintain an application level service. For example the Forum service Administrator would perform the following, and other, functions:

• May add, edit, delete, and reorder the forums, categories, and links.
• Manage User Accounts
• Manage Group Accounts
• Manage Board Level Settings ( Email, Template, etc )
• Support the Service Moderator's

These individuals are selected by the OUCV alone. The service administrator role is enabled through and provided by the relevant service application. No action is required by the hosting provider to grant these privileges.

Service Moderator

Moderator is a supporting administration role supported by some application services. For example in the case of forums, moderators have an elevated level of privilege which enables them to modify or delete user posts that violate site policy (e.g. SPAM or obscenity). Service Moderators are selected by the OUCV Voting Process. No action is required by the hosting provider to grant these privileges.

Content Manager

These individuals are selected by the OUCV alone. The Content Manager role is enabled through and provided by the relevant service application. Where required Content Manager's may be granted User Account Interactive Access and limited datadase access.

Ombudsman

The Ombudsman's role and responsibilities include:

• Administration and oversight of all polls
  • The ombudsman can mandate that any specific vote be opened to the general membership, where he or she feels that there is a reasonable case for doing so.
• NON-Voting member of all change control boards to represent the general membership. (do we have a process for this?)
• Management and arbitration of Membership complaints.

To avoid conflict of interest the Ombudsman cannot hold any other User Community Role.

Chronicler — Tie-breaker, spokesperson

• Shall be the official spokesperson for the organization on issues related to the interests and purpose.
• This person is not to vote unless there is a tie that freezes the issue at hand.

The Projects Manager

• Shall assist in infrastructural development so that documentation of projects is done to some extent.
• Maintains the projects' wiki pages.
• Shall take charge of post-mortems of projects so useful information can be amassed as to what structures worked and what didn't.

Group Publicity Person — OO.o Evangelist

• Shall come up with fun and useful "virtual events" that promote the use of OO.o and the support forums at the site.
• Shall abide by all local regulations and group agreements when promoting the organization or its views.

Footnotes

Limitations on Site Access

Some transactional rate limiting mechanisms may apply to prevent robot users from degrading the performance of the site for normal interactive users. We also need to consider whether we bar certain users and / or IP address/domains (based on bots, spam, abuse, etc).

Site Registration Process

The Site Registration Process has two variants:

• The standard process is for a Guest who wants to become a Member; a Member can post, a Guest can not. The main purpose for registration, is is to associate changes made by a user with an identity. For example, a common forum feature is to list posts by author. The registration process will minimize SPAM bots through use of tools such as a "Captcha" or equivalent. A valid contact email address is required along with a response to an email sent to the submitted address. The email address is retained as confidential and not published to general members without authorization by the Member. The email address provides a means of contacting the members, but is only available to the system (for automated requested contacts such as a forum topic has been updated) and to members with specific roles such as a system administrator or moderator. A Guest can not become a member without a valid, verified, contact address. There are various other optional fields that the User can specify.

• A stricter process controls the transition from Member to Volunteer, and from Volunteer to normal Member. Volunteers may be appointed to trusted roles, so the UCV must have confidence in the provenance and credentials of the Member.
  • A forum exists for discussing the Registration Process. Although only Volunteers can post to this forum, all Members can view the forum⁽⁺⁾.
  • All applications for promotion to or removal from Volunteer status are posted to this forum as a new topic. Any Member can make an application through a Volunteer (for example the ombudsman) which typically contains a brief identity (name, country, work experience, etc.) and a short personal statement of why the candidate wishes to become a Volunteer.
  • Any Volunteer may comment on the application.
  • Any Volunteer may explicitly designate approval.
  • Any Volunteer may explicitly designate a protest.
  • The application is open for [two] weeks.
  • If at the end of this period at least two approvals and no protest have been made then Volunteer status change is granted.
  • The change is declined if there are not at least two approvals.
  • If there are least two approvals and at least one protest, a vote of the UCV membership is performed under the standard UCV voting procedure.
  • Where the application is declined, reapplication can be made after [3] months.

(+) There are issues of disclosure that we need to think about here. See the Talk page for further discussion on this.

OUCV Voting Process

Members of the Volunteer site team may hold votes on topics within their areas of interest separate from those interests voiced by Registered or unregistered users of the site. Technical issues of interest to Volunteers may include any topic, including which issues will be decided by general Registered Member votes. Topics under consideration will be posted to a Forum category devoted to these issues and the results will be posted there as well. Registered members may comment on these issues or raise questions.

Voting Guidelines

General Voting on issues of importance to the members regarding the site or the management will take place quarterly on the first Tuesday of January, April, July, and October. A Forum category will be set up devoted to these issues and the results will be posted there as well. Only registered site members will be able to vote in these quarterly events. In most cases, a simple majority vote will suffice. This means in the case of a stand-off, a vote will be rescheduled for the next quarter.

Please do not change the logical content of this page without first discussing this on the Talk Page and acknowledgement from the UCV Contact list.