Archive:Proposals/Policy
Template:TOC-right This page reviews the specialized rules for managing the proposals system. All the basic information you should need to make (i.e., start) a proposal is located on CZ:Proposals. You need to read the following only if you want to be a proposal "driver."
The purpose of the proposal system
The proposal system should
- serve as a single, central location for proposals about the Citizendium.
- manage and drive proposals forward, if necessary without the intervention of the Editor-in-Chief or certain other active Citizens; to make sure that proposals get as far forward as possible as efficiently as possible.
- explain and clarify to people just how their own proposal can be adopted with a minimum of unnecessary bother and confusion.
In other words, this system is designed to let people "take charge"--to act and drive forward, not just to debate and complain.
The proposal process
There is not much of a set "process" for proposals, beyond a few simply-stated steps: (1) start the proposal; (2) assign the proposal to a decisionmaking group; (3) develop the proposal as appropriate; (4) put it in the hands of the decisionmakers; and (5) if accepted, implement it. Each of these steps is elaborated below.
Start the proposal
Basic user instructions to start proposals are on the proposal system homepage. This involves creating a proposal record, which must be complete (see below) and well formed (see below). Also, the proposal must have a person to drive it toward adoption (see below).
Assign the proposal to a decisionmaking group
Once a proposal record is complete and well formed, the Proposals Manager assigns it to a decisionmaking group (if any), moving the proposal record to a particular queue, such as CZ:Proposals/Constabulary. The Proposals Manager puts at the top of the proposal page just what decisionmaking group (or ad hoc person(s)) is responsible for making the final decision about, and implementing, the proposal. (There is [will be] a simple template for this purpose: ________.)
To determine what groups are assigned what topics, see the table below.
Individually and ad hoc managed: there might be some unusual, or relatively unimportant (but not trivial) matters that it would not make sense to bother an entire decisionmaking body (Editorial Council, Constabulary, or Executive Committee) with. The Proposals Manager may name a specific individual (either the driver or someone else) or an ad hoc group of people, who will be charged with making the final decision whether the proposal is to be accepted. If the head of any appropriate decisionmaking group asks to take on a proposal, however, rather than it being made an individual or ad hoc group that makes the decision, then that decisionmaking group should be charged with the decision.
In case of disagreement about venue of decision, the venue should be discussed on the proposal page (see below). If negotiation cannot elicit agreement, the decision of the Editor-in-Chief will be final. It is possible that, in the future, a Judicial Board will handle such questions.
Develop the proposal or issue
Once the proposal has been assigned to a group, the full proposal--beyond the mere proposal "record," or what appears in the yellow box--should be developed. (It is fine to develop the full proposal before that.)
See below for details about the requirements of a proposal page.
Put the proposal in the hands of the decisionmakers (if necessary)
To determine how to "put the proposal in the hands of the decisionmakers," see the table below.
Implement the proposal (if accepted)
For notes on how to implement a proposal, see the table below. It will differ from group to group, but generally, it should already be part of the proposal exactly how it will be implemented: if there is no feasible way to implement a proposal, we should not consider it "accepted and just waiting to be implemented." Otherwise, we are apt to pile good intentions upon good intentions, and never take the question of implementation with the seriousness that it deserves.
One crucial aspect of implementation is that community and policy pages must be rewritten or newly created. Thus must be done with a view to retaining the simplicity, consistency, and narrative flow of instructions and policy explanations.
Components of a proposal "record"
A proposal "record" is what is contained in the yellow boxes on CZ:Proposals/Initial and, once moved from the initial page, the various subpages. That box is generated by the {{proposal}} template, which a proposer fills out and a proposal driver maintains. Here are some salient details about each item in the template.
- Brief descriptive title: should be quite brief, as this will become part of a wiki page name.
- Summary: should be no more than 100 words. This is just a summary; the full proposal is located on a new page you create (on which, see below).
- Name and date of original proposer: type
~~~~; the username of the person who added the proposal to CZ:Proposals/Initial and the date and time added. The system doesn't care who "originally had the idea," but we'll give credit to the person who makes the proposal. - Username of driver: the "driver" is a person who commits to moving the proposal toward approval and action. See below.
- Next step: a phrase or sentence describing the next most immediate goal that will have to be achieved, in order to get the proposal adopted and put into action. See below.
- Target date for next step: this is a specific date (e.g., April 15, 2008), not something unclear like "soon" or "sometime" or "in a week."
- Notes: optional. These are any notes the proposer or driver feels necessary to include as part of the proposal record. Detailed notes belong on the full proposal page (again, see below).
When is a proposal record well formed?
In order for a proposal to move from CZ:Proposals/Initial to a group page (such as CZ:Proposals/Constabulary), it must be "well formed." That means (1) all the above data needs to be filled out, and (2) the proposal itself must be non-trivial, impersonal, and serious:
- Non-trivial: things that do require a proposal though are issues that have sweeping impacts in the entire CZ community, or across different disciplines or workgroups. Some things can be done swiftly, and by individual empowerment. It doesn't take a community to fix a leak. If a few citizens choose to band together to perform certain content initiatives, then there's no need to ask for input: as with a certain shoe company, "just do it!" When in doubt, ask the Proposals Manager for advice.
- Impersonal: proposals may not be to remove any person from any position within CZ or from the project altogether; nor may they have the explicit or implicit purpose of criticizing a person.
- Serious: jokes, ironic statements, rants, etc., do not count as proposals. They will simply be deleted by the Proposals Manager.
If a proposal record is incomplete, it will remain on CZ:Proposals/Initial for a week. If it is then still incomplete, the record will be moved to CZ:Proposals/Discarded. Proposals that are not serious, or trivial, or personal, will either be moved to CZ talk:Proposals/Initial for commentary, or simply deleted outright, depending on the case.
The proposal driver
Anyone may be a proposal driver. The driver takes responsibility for maintaining and updating not only the proposal record (see above) but also the main proposal page as well (see below). The driver also takes responsibility for actually writing, defending, and negotiating about the proposal, up to the point where it is submitted to a decisionmaking body, such as the Editorial Council or the Constabulary. If a person must be a member of the decisionmaking body in order to present it to that body, then the driver is responsible only for making sure the proposal is sponsored by a member of the decisionmaking body.
Please bear in mind that, merely because you are the proposal's driver, you do not therefore have the exclusive right to determine the shape of the proposal. That should be determined first by negotiation with other interested Citizens (see above), and then (if necessary) by the decisionmaking body (see above).
The driver can be, but is not necessarily, the proposer. If a proposal has no driver, it will be dropped (see above). An idea can be great, but if no one is interested in championing it, it won't happen.
If there is another person who is working a lot on the proposal, then you as driver might want to add that person as co-driver. Also, the Proposals Manager might in some cases opt to add another driver to a proposal you are driving, or even to replace drivers. A driver should be replaced only if, in the opinion of the Proposals Manager or the Editor-in-Chief, there is a clearly better-qualified person who is highly motivated to drive the proposal.
Decisionmaking groups
| Group | Remit (topics of responsibility) | How to contact | Acceptance and implementation notes |
|---|---|---|---|
| Editorial Council | naming conventions; article standards; article deletion, including policies regarding when the Constabulary may delete an article; editorial dispute resolution; editor registration; the Topic Informant Workgroup; the list of workgroups; the process of creating new workgroups; the process of choosing Chief Subject Editors; editor review policy; media; all questions regarding subpage content and format; and Editorial Council operations and personnel. | If the driver is not a Council member, and no Council member is ready to sponsor it and make it into a resolution, then (1) e-mail the Secretary of the Council (Dr. Supten Sarbadhikari, supten@gmail.com) and (2) add a copy of the proposal record to Editorial Council Suggestion Box. The Secretary then has the responsibility of posting (if necessary) repeated calls for sponsorship. If no Council member will sponsor the resolution after three calls, it may be considered declined. | A proposal is accepted once it is converted into an Editorial Council resolution and the resolution passes. Implementation notes are a required part of Council resolutions. |
| Approval and Feedback | article approval standards, templates, and process; creative efforts to increase approval rates; any and all content feedback systems for articles and subpages. Note that this group is overseen by and answerable to the Editorial Council. | E-mail the Approval and Feedback Editor (not yet selected). | Acceptance will be determined by vote of Approval and Feedback Workgroup. Note that implementation may require coordination with the Technical Team, and no proposal can be accepted unless there is a commitment of resources (including volunteer coders) to make it happen. |
| Eduzendium | general Eduzendium policy, recruitment, and management. Note that this group is overseen by and answerable to the Editorial Council. | E-mail Sorin Matei (smatei@purdue.edu) and Lee Berger (profleeberger@yahoo.com) or leave a message on their user talk pages. | Sorin and Lee will decide on all Eduzendium matters, if necessary in consultation with the Editor-in-Chief. |
| Recruitment | all matters concerning recruitment, motivation, and retention, except for rules concerning author and editor qualifications (which are handled by the Editorial Council and the Constabulary, respectively). Note that this group is overseen by and answerable to the Editorial Council. | E-mail the Recruitment Lead (not yet selected). | To begin with, the Recruitment Lead will decide all new recruitment proposals. If the initiative gains multiple active members, they may vote. Similar caveats about technical components of proposals apply. |
| Constabulary | author registration and leaving; abuse (e.g., vandalism) and account blocking for abuse; professionalism; and Constabulary operations and personnel. | E-mail the Chief Constable, Ruth Ifcher (rose.parks@att.net). | The Constabulary will both decide and take the lead in implementing any Constabulary proposals. |
| Executive | pretty much everything else, including new projects not within the remit of the Editorial Council; the proposals system in general; partnerships; fundraising; employee management; the Editor-in-Chief; and Executive Committee operations and personnel. | E-mail the Editor-in-Chief, Larry Sanger (sanger@citizendium.org). | Often, implementation of Executive Committee matters requires direct involvement of the Editor-in-Chief. It is more likely to be accepted if it is a proposal that someone else is already committed to doing. |
| Technical | server operation; extensions; other technical stuff; technical team operations and personnel. Note that this group is overseen by and answerable to the Executive Committee. | E-mail the Technical Lead (not yet selected) as well as bugs@citizendium.org and Citizendium-Tools@citizendium.org. | Bear in mind that no proposal can be accepted unless there is a commitment of resources (including volunteer coders) to make it happen. So, once the technical team has accepted a proposal, they have committed themselves to implementing it, or (in any event) they have seen to it that it will be implemented. |
| PR | press releases; wiki design and branding. Note that this group is overseen by and answerable to the Executive Committee. | E-mail PR Lead, Ian Johnson (Ian.Johnson@OutNowConsulting.com) who should forward the mail to the PR group list. | As with the Executive Committee, proposals are much more likely to be accepted if it is a proposal that someone else is already committed to doing. The PR group is (currently) very small and busy. |
| Proposals System Navigation (advanced users only) | |
|
Proposal lists (some planned pages are still blank):
|