Archive:Proposals/Policy

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

1. serve as a single, central location for proposals and issues about the Citizendium.
2. 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.
3. 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, and make sure the proposal record is completely filled out.

The Proposals Manager does this: if a proposal is incomplete, send reminders to finish the proposal (see below); if, a week after new proposal, a proposal is still incomplete, the proposal record should be moved to CZ:Proposals/Discarded; if a proposal is not actionable, trivial, personal, or not serious, it can be moved sooner to CZ talk:Proposals/New for commentary, or simply deleted outright, depending on the case. Note: to get the proposal ready for assignment, the Proposals Manager may copyedit the proposal record summary, and may add next steps and dates, if they are not provided by the driver.

Note about proposals vs. issues: a proposal recommends one course of action, while an issue asks which of two courses of action we should take. Therefore, issues should present two or more definite, well-defined options, at least two of which are not the status quo. If you wish to ask us to decide whether to adopt a proposal or else maintain the status quo, you should formulate a proposal, not an issue. There is, after all, always the negative option for any proposal, which maintains the status quo.

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}} (which see). To determine what groups are assigned what topics, see the table below. Please also be familiar with the notes about venue. At the same time the Proposals Manager moves the proposal record, he or she should add a note to proposals recently moved about where the proposal was moved.

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 "driverless" page.

Components of a proposal "record"

A proposal (or issue) "record" is what is contained in the yellow boxes on CZ:Proposals/New and, once moved from the new 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/New 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/New 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, political statements, 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/New for a week. If it is then still incomplete, the record will be moved to CZ:Proposals/Discarded. Proposals and issues that are not actionable, trivial, personal, or not serious, will either be moved to CZ:Proposals/Discarded, 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 has become "driverless."

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.

1. Develop the proposal page completely
2. Get more feedback
3. Get feedback from X (a specific person)
4. Revise the proposal
5. Submit the proposal to G (a group)
6. Wait for a response to the proposal
7. 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:

1. 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).
2. 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.
3. The reasoning behind the proposal, or behind the various options offered in the issue. This should explain what problem the proposal is meant to solve, and why it will solve that problem.
4. An explanation of who will implement the proposal, and how. If there is no one to implement the proposal (as, for example, with many technical or recruitment proposals), then it is automatically declined, and should not be submitted to the decisionmakers (i.e., it should not move on to step 3, above).
5. A discussion section, to which anyone may contribute.

Decisionmaking groups

Note that only the Proposals Manager should assign proposals to a decisionmaking group.

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 e-mail the Secretary of the Council (Howard C. Berkowitz). 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 cz-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.
Ad hoc (not a set group)	See notes about venue.	Contact info depends on who the decisionmaking person(s) are. Often, they'll already be tracking the proposal page.	See notes about venue.

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:

1. Monitor the proposals system on a daily basis (or as often as needed).
2. Move proposal records from queue to queue, as appropriate. (For this, you should familiarize yourself with the various queues, listed below in the navigation box.)
3. Assign proposals to decisionmakers (see above).
4. Answer questions about how the system works, by e-mail, on the user talk page, on CZ talk:Proposals, and on individual proposal pages.
5. Edit proposal records and proposal pages for format (e.g., fix broken templates), but not for content. For example, to get the proposal ready for assignment, the Proposals Manager may copyedit the proposal record summary, and may add next steps and dates, if they are not provided by the driver.
6. Resolve problems when different proposals make contradictory recommendations (generally, consolidate them and make them into an issue).
7. Time permitting, send reminders and notices to proposers and drivers. Update the next step and "to be done by" fields, as necessary (but the driver should be doing this).
8. Remove drivers who demonstrate inadequate commitment to driving their proposals along. This involves blanking the driver and "to be done by" fields, as well moving the template to the driverless proposals queue. It would be good if the Proposals Manager would, at the same time, post an announcement to Citizendium-L that the proposal needs a driver.

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. The Proposals Manager serves as proxy of the Editor-in-Chief. This person should consult with the Editor-in-Chief (only as necessary), and should be a member of the Executive Committee. This is particularly because the overall management of policy and process development in the Citizendium is essentially the job of the Editor-in-Chief.

Proposals System Navigation (advanced users only)

Help/policy New proposals List of all proposals Driverless proposals: proposals that lack a champion Discarded proposals: poorly formed proposals Templates: {{Proposal}} | {{Proposal assignment}} | {{Proposals navigation}}

Proposal lists (some planned pages are still blank): Editorial Council: Active | Finished | Declined Approval and Feedback: Active | Finished | Declined Eduzendium: Active | Finished | Declined Recruitment: Active | Finished | Declined Constabulary: Active | Finished | Declined Executive: Active | Finished | Declined Technical: Active | Finished | Declined PR: Active | Finished | Declined Ad hoc management: Active | Finished | Declined