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 (or issue) 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 and issues about the Citizendium.
- manage and drive proposals and issues forward, if necessary without the intervention of the Editor-in-Chief or certain other active Citizens; to make sure that proposals and issues get as far along to decision and implementation as possible, as efficiently as possible.
- explain and clarify to people just how their own proposal can be adopted, or issue decided, 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 and issues, beyond a few simply-stated steps:
- (1) start the proposal or issue;
- (2) develop the proposal or issue as appropriate;
- (3) put the decision in the hands of the decisionmaker(s) (if necessary); and
- (4) if accepted, implement it. Each of these steps is elaborated next.
Below, we've stated what proposers, drivers, and the Proposals Manager do (if anything) at each step.
1. Start the proposal or issue
The proposer does this: start the proposal or issue! Basic user instructions to start proposals are on the proposal system homepage. This involves creating a proposal record, which must (eventually) be complete (see below) and well formed (see below). Also, the proposal must have a person to drive it toward adoption (see below).
The driver does this: volunteer to become driver.
The Proposals Manager does this: if a proposal is incomplete, send reminders to finish the proposal (see below); if a proposal is trivial, personal, or non-serious, it should be moved to CZ talk:Proposals/Initial for commentary, or simply deleted outright, depending on the case; if, a week after initial proposal, a proposal is still incomplete, the proposal record should be moved to CZ:Proposals/Discarded.
2. Develop the proposal or issue
The driver does this: develop the full proposal, beyond the mere proposal "record," or what appears in the yellow box. This is the main job of the driver. Do see below for details about the requirements/recommendations for a proposal page.
The Proposals Manager does this: assign the proposal or issue to the decisionmaker(s). 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 a simple template for this purpose: {{proposal assignment}}. To determine what groups are assigned what topics, see the table below. Please also be familiar with the notes about venue.
3. Put the decision in the hands of the decisionmaker(s) (if necessary)
The driver does this: put the decision in the hands of the decisionmaker(s). To determine how to "put the decision in the hands of the decisionmaker(s)," see the table below. This varies from group to group. If the driver is also the decisionmaker, this step is effectively skipped (presumably, the driver will approve his or her own proposal).
The Proposals Manager does this: usually, nothing. In case the decisionmakers are the persons following the discussion of the proposal on the proposal page, then the decision may be made as soon as it is clear that there is a 2/3 majority in favor of the current form of the proposal, and they may move to the implementation step automatically. If there is any question about whether there is in fact a 2/3 majority, an actual vote must be taken on the page; the Proposals Manager may oversee this process, only to make sure it is correctly set up and fair.
4. Implement the proposal (if accepted) or issue (if decided)
The driver does this: take the lead in implementation, or else ensure that implementation is happening. For notes on how to implement a proposal or issue, 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. Note: one crucial aspect of implementation, particularly of issues, 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.
The Proposals Manager does this: once implementation begins, move the proposal record to the "finished" page. Note that if implementation does not occur, and the driver "drops the ball," the proposal must be moved to the "stalled" page.
Components of a proposal "record"
A proposal (or issue) "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. If an issue, this is preferably stated in the form of a brief question.
- Summary: should be no more than 100 words. This is just a summary; the full proposal (or the competing positions of the issue) is located on a new "proposal page" you create (on which, see below).
- Name and date of original proposer: type
~~~~; the username of the person who added the proposal or issue 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 or issue toward approval/decision 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 or issue 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 actionable, non-trivial, impersonal, and serious:
- Actionable: proposals must be clear and definite enough to be actionable. If a proposal is so vague that we have no clear idea what action would need to be taken if it were enacted, and in particular, if a driver can't be reasonably expected to know just how to develop it, then it is not a well-formed proposal.
- Non-trivial: things that do require a proposal or issue have sweeping impact in the entire CZ community, or across different workgroups or initiatives. 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 and issues 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/issues. 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 and issues 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.
Keeping the proposal moving along
To keep the proposal moving along, the system requires the driver to specify a "next step" and a due date for the next step. This is used by the Proposals Manager, to send reminders and, if necessary, determine that a proposal is "stalled."
But what are some possible next steps, in general? Here are some ideas. They are only ideas; the proposal does not have to go through these steps. It could skip many, add many, and go back.
- Develop the proposal page completely
- Get more feedback
- Get feedback from X (a specific person)
- Revise the proposal
- Submit the proposal to G (a group)
- Wait for a response to the proposal
- Implement (this could have many substeps, and note that a proposal or issue cannot be considered finished until its implementation has started)
The proposal driver
Any Citizen may drive a proposal or issue. 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 the decisionmaker(s), such as the Editorial Council or the Constabulary. If a person must be a member of a 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. The driver also begins implementation.
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.
Please bear in mind that, merely because you are the driver of proposal or issue, you do not therefore have the exclusive right to determine the shape of the proposal/issue. That should be determined first by negotiation with other interested Citizens, and then (if necessary) by the decisionmaking body. This is particularly important to bear in mind with issues: the driver must take great care to state the different options as fairly as possible.
If you simply have no interest in converting a proposal, which presents your preferred plan, into an issue, which gives the community two or more options to consider, you need not do so. In particular, you are not obligated to articulate another option to which you are opposed. You generally should, however, allow another person or persons to articulate that option and thereby become a co-driver of the issue. The Proposals Manager should be called upon to supervise the conversion of a proposal into an issue; while he or she must pay attention to and respond fairly to arguments on all sides, his or her determination as to who may drive a proposal/issue will be regarded as final. Appeals on such controversies can be made to the Editor-in-Chief, but only after the Proposals Manager has made a determination. The Editor-in-Chief will overrule the Proposals Manager only if unusual neglect, obvious bias, or other clear problem with process is noted.
The proposal page
The "proposal page," which may concern either a proposal or an issue, and which you reach from a queue by following the "complete proposal" link, should have five items:
- The decisionmaking group (or a list of person(s)) to which the decision is assigned. While this is open to debate, only the Proposals Manager (or Editor-in-Chief) may actually make or edit the assignment (using the {{Proposal assignment}} template).
- A complete, clear, feasible, and (as applicable) step-by-step explanation of the proposal. Or, if an issue: a complete and fair explanation of the competing positions that the decisionmakers are being asked to consider. If a proposal contradicts an existing rule, that fact should be acknowledged, and the proposal should be formulated as an amendment to the rule.
- The reasoning behind the proposal, or behind the various options offered in the issue.
- An explanation of who, and how, the proposal will be implemented. If there is no one to implement the proposal (as, for example, with many technical or recruitment proposals), then it is automatically declined.
- A discussion section, to which anyone may contribute.
Decisionmaking groups
| Group | Remit (topics of responsibility) | How to contact | Decision 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 the proposal/issue 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) or leave a message on his user talk page. | 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. |
Notes about venue
The Proposals Manager is tasked with determining who the decisionmaker(s) for any given proposal or issue will be (see Step 2 in the proposal process, above). This can be a decisionmaking group, in which case the above table should be used.
But there might be some unusual, or relatively unimportant (but not trivial) matters that it would not make sense to bother an entire decisionmaking body 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 or issue, 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.
The Proposals Manager may, in lieu of anything better, elect to say that all the people who comment on the proposal on the proposal page constitute an ad hoc decisionmaking group. In that case, support (for the proposal, or for one of the options in an issue) at the level of a 2/3 majority is required. That is because, if the proposal is so controversial as to receive only 51%, then it should probably be decided by a more carefully-chosen group, such as the Editorial Council.
In case of disagreement about venue of decision, the venue should be discussed on the proposal page (see above). 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.
The Proposals Manager
The Proposals Manager is the main administrator of the proposals system. He or she is expected to be an "honest broker," not taking stands on controversial matters, and must also be thoroughly familiar with the rules of the system. The Proposals Manager has several basic functions:
- Monitor the proposals system on a daily basis (or as often as needed).
- Move proposal records from queue to queue, as appropriate.
- Assign proposals to decisionmakers.
- Answer questions about how the system works, by e-mail, on the user talk page, on CZ talk:Proposals, and on individual proposal pages.
- Edit proposal records and proposal pages for format (e.g., to fix broken templates), but not for content.
- Time permitting, send reminders and notices to proposers and drivers.
The more precise functions of the Proposals Manager, and how to perform them, are described throughout the above document.
The Proposals Manager should be a person of unusually mature judgment who is broadly familiar with Citizendium governance. If the workload should become too much for one person, we may add more Proposals Managers.
| Proposals System Navigation (advanced users only) | |
|
Proposal lists (some planned pages are still blank):
|