Proposal of CZ:Proposals

[Robert_W_King]

Really? I thought it was simple    Please enlighten!

[Larry Sanger]

Robert: I'll enlighten by redoing it later today or tomorrow, if you don't do it before I do.  I want to get this whole thing finished and ready to present to the larger community and the Executive Committee ASAP, so I can move on to the job descriptions page and the big partnership invitation.

Steve: I don't think that templates are by their nature innocuous.  While they can be harmless, as a class they have a host of disadvantages: they often make pages look messier/more complex; they can impose subtle requirements, or "suggestions" that quietly and without debate morph into requirements; and they can be forbidding to many people who don't understand templates and who think they really should, or even must, use them.  Now, what this means for how we adopt new templates, and whether they should go through any process at all, I'm not entirely sure.  But I do know that we should not simply adopt the stance that anyone may adopt any template he wants and start plugging that everyone use it.  That's essentially undemocratic; it's anarchical and reminds me of Wikipedia. 

[Warren Schudy]

I want to get this whole thing finished and ready to present to the larger community and the Executive Committee ASAP, so I can move on to the job descriptions page and the big partnership invitation.

According to the executive committee webpage (http://en.citizendium.org/wiki/CZ:Executive_Committee):

As a rule, the Committee should handle only those matters that need to be private—as, for example, grant proposals, partnership proposals that have not been reviewed, major outlays, as well as the "strategy" of the use of the Editor-in-Chief's time.

Is that description of the Executive Committee wrong? Why does the proposals initiative need to be private?

[Larry Sanger]

Onto the next Big Question:

How are proposals listed?  (The suggestion that it be a "queue" implies first-in, first-out.  Is that right?)  Are there to be various subpages of proposal, perhaps divided into categories, or not?  If not, how do we deal with the problem of "too many proposals"?  Careful, this is where the system might end up getting really messed up.

The problem I have in mind is that, just as with lists of feature requests and bug reports, after the list gets long enough, it becomes too long to just scan.  This is a serious problem, not just from the perspective of someone reading up about what our proposals are, but for purposes of managing the proposals themselves.

Once there are too many items in a list, the suggestion will naturally be that we should divide them up, either in sections in one large page, or on subpages (or an interconnected set of pages).  That's right; and we should anticipate that necessity now.  So how should proposals be organized/sorted?

To answer this, I advert once again to the purposes of the system.  The system is set up to make it as easy as possible for people to make proposals, to track them, and to ensure that they are decided and acted on.  For these purposes, I imagine two different categories of proposals: by decisionmaking group (Editorial Council, Constabulary, an individual workgroup, etc.) and by urgency/impact.  We could, for example, create [[CZ:Proposals/Constabulary]], [[CZ:Proposals/Eduzendium]], and so forth; or we could create [[CZ:Proposals/Top Priority]], and so forth.  Then, of course, we could further sort group-managed proposals by priority, and we could sort top priority proposals by managing group.

What would be most useful, helpful, and clearest to rank-and-file Citizens using the proposal system?  Well, people have specific interests (they're more interested in Editorial issues than Constabulary issues, for example) so sorting by managing group would be useful for that reason.  Also, the community as a whole has a significant interest in prioritizing issues.  So I'm inclined to sort by both.  But I would suggest sorting first by managing group, because there is no reason to prioritize issues and proposals handled by different groups, which each have their own way of proceeding.

In addition, I would like to have a queue for initial proposals, perhaps on [[CZ:Proposals]] itself (if not [[CZ:Proposals/Initial Sorting]]), and this would be first-in, first-out.  So a proposal starts life on the initial proposals page, and then goes to one of the group-managed proposals pages.  Exactly who decides where a proposal goes, and how this is decided, is something to discuss a little later on.

I also want to limit the total number of proposals on a page (except for the initial queue page).  A good round number is 10, but even that might be too many; perhaps five would be better.  All other proposals for a given group would go on a "proposals overflow" page.  This, again, is for maximum simplicity.  Anyone might try to move one of the "overflow" proposals forward, if they feel so motivated, but the proposals that we as a community are "officially" or strongly encouraging work on must be limited in number.  I suspect that over time, there will be dozens, then even hundreds of proposals for every group; but some of the proposals, regardless of their merit, will never rise to the level of mere consideration simply because we have higher priorities.

There is one addition I can make here...if the proposal system starts being overused, it could become sort of the jumping-off page for a new sort of wiki discussion forum.  That's precisely what we don't want to have happen, because the purpose here is not discussion but actual action.  Action requires prioritization.

The latter implies that we should add another rule (to go with the off-to-the-side "legalistic" rules) about the form/requirements of the proposals themselves.  Namely, if a proposal is trivial, it shouldn't be included on the proposals page.  This then raises a question we'll have to address at some point: what exactly is a "trivial" proposal?   Good examples are Thomas Mandel's two submissions: proposing the changing of a wording of the top of the page belongs elsewhere; similarly the design of a tag.  Those things are simply too trivial to merit inclusion on the proposals page.  They should go, well, somewhere else.  They shouldn't be included in the queue because they do not require a lengthy public debate, they're taking up space on the proposal page that would be used for far more consequential matters, and they confuse potential users about what the function of the proposals system even is.  I would be opposed even to shunting them off to an "overflow" page; overflow should not include a huge amount of sheer cruft.

By the way, I just thought of another rule on that: proposals that are very similar to, and particularly in conflict with (or that need coordination with) an existing proposal, should be combined with/added to the existing proposal.  If in conflict, then the original proposal should be changed from a proposal into an issue (defined above) for decision.

And another: proposals that concern individual articles are not well-formed.  Any matter whatsoever about an individual article should be handled within other processes than the proposals process.

[Larry Sanger]

I want to get this whole thing finished and ready to present to the larger community and the Executive Committee ASAP, so I can move on to the job descriptions page and the big partnership invitation.

According to the executive committee webpage (http://en.citizendium.org/wiki/CZ:Executive_Committee):

As a rule, the Committee should handle only those matters that need to be private—as, for example, grant proposals, partnership proposals that have not been reviewed, major outlays, as well as the "strategy" of the use of the Editor-in-Chief's time.

Is that description of the Executive Committee wrong? Why does the proposals initiative need to be private?

That's a fair question.  I've changed the wording of the page to reflect better the committee's actual purpose: "The Executive Committee of the Citizendium works privately, in order to advise the Editor-in-Chief on questions he puts to them, and especially to help make decisions about relatively confidential matters."  The Executive Committee does not vote and thereby make decisions; I make the decisions after taking what they say very seriously.  They advise me.  Actually, I just noticed that there's a line further down that makes this clear: "As a general rule, any policy discussions that take place by the Executive Committee will be aimed to assist the Editor-in-Chief in making up his own mind."

So in this case, when I consult them, I am not really asking them to vote on and thereby approve the proposal.  I am asking them to give me feedback to improve the proposal.  As to how the proposal will actually be legitimately approved, that happens quite simply by my declaring that it's official.  I just won't do so, however, over many loud and persuasive objections from the community, and I will be (again) soliciting feedback from the community in general when the system is better developed.

Perhaps there should be an independent voting body (and perhaps it could be the Executive Committee, I don't know) that handles questions that are not obviously matters for the E.C. or the Constabulary.  What I do know is that the way that other decisions are made needs to be made official, or settled; and very possibly it should not be just a matter of the Editor-in-Chief deciding.

[Warren Schudy]

The latter implies that we should add another rule (to go with the off-to-the-side "legalistic" rules) about the form/requirements of the proposals themselves.  Namely, if a proposal is trivial, it shouldn't be included on the proposals page.  This then raises a question we'll have to address at some point: what exactly is a "trivial" proposal?   Good examples are Thomas Mandel's two submissions: proposing the changing of a wording of the top of the page belongs elsewhere; similarly the design of a tag.  Those things are simply too trivial to merit inclusion on the proposals page.  They should go, well, somewhere else.  They shouldn't be included in the queue because they do not require a lengthy public debate, they're taking up space on the proposal page that would be used for far more consequential matters, and they confuse potential users about what the function of the proposals system even is.  I would be opposed even to shunting them off to an "overflow" page; overflow should not include a huge amount of sheer cruft.

Who or what body has the authority to replace the Citizendium logo? It's certainly not a major decision worthy of voting in a committee, but it seems too important for a Citizen to just do. Currently, the only person who appears to be authorized to make minor decisions that are not specific to one workgroup is the Editor-in-Chief. I bet this is the primary cause of the lack of initiative that Larry keeps complaining about. Is the [[CZ:Proposed_Leadership_Roles]] proposal intended to solve this problem?

[Larry Sanger]

Who or what body has the authority to replace the Citizendium logo? It's certainly not a major decision worthy of voting in a committee, but it seems too important for a Citizen to just do. Currently, the only person who appears to be authorized to make minor decisions that are not specific to one workgroup is the Editor-in-Chief. I bet this is the primary cause of the lack of initiative that Larry keeps complaining about. Is the [[CZ:Proposed_Leadership_Roles]] proposal intended to solve this problem?

Yep.  That's precisely the general idea.  I agree with your analysis entirely.

[Robert_W_King]

Robert: I'll enlighten by redoing it later today or tomorrow, if you don't do it before I do.  I want to get this whole thing finished and ready to present to the larger community and the Executive Committee ASAP, so I can move on to the job descriptions page and the big partnership invitation.

Then you'll have to make the changes because without explaining what needs to be changed I can't make any adjustments.

[Larry Sanger]

When a proposal is made, then what generally happens to it?  Bear in mind that it is not (never was) part of the purpose of the proposals system to make decisions about proposals, but simply to track them.

In short, what should the process look like?  Here the thing to bear in mind is that it should be as simple as possible.  The more complex that the process of introducing and tracking proposals is, the more we defeat the purpose of simplifying and facilitating bold, creative development of the project.

What, then, are the absolutely essential steps of the proposals system?  (1) Ensure that a proposal is well-formed.  (Essential because then the queues will fill up with poorly-formed proposals, which is self-defeating.)  (2) Move the proposal to more specialized queue/list.  (Essential because the main queue page will get too long and confusing, otherwise.)  (3) The proposal must be updated with status information from time to time.  (Essential because the purpose of the system is in part to track and manage proposals, and status info is crucial to tracking & management.)  (4) Move a proposal to a "finished proposals" (or whatever) page, when they have been adopted, rejected, acted upon, etc.

There might be a few more to add, as we ramp up the system.

Robert (to your most recent comment): agreed.  There are so many tiny things I would change that it would be more efficient for me just to make the changes myself.  It shouldn't take that long.

[Martin Baldwin-Edwards]

I was sort of following this from a distance, but decided to make one comment here: it is not a good idea for everything to be loaded onto the Editorial Council and [separately or combined] the Editor in Chief. In my opinion, the Ed. Council should be confined to editorial matters, and not attend to other issues of governance. This means that there is a lacuna: the obvious thing to do would be to restructure the Executive Committee so that it does not "advise the E-i-C" but actually makes policy relating to general management issues.

I realise that this is sort of peripheral to the whole focus here, but it seemed relevant. This debate should also inform your revision of the purpose and structure of the Ed. Council, Larry.

[Larry Sanger]

Exactly who decides where a proposal goes, and how is this decided?

Basically, I want this decision made by someone who serves as proxy of the Editor-in-Chief.  In other words, there is a person who is specially commissioned to look over and update the page and has broad authority to make certain decisions about it.  This person should consult with the Editor-in-Chief (only as necessary), and should be a member of the Executive Committee.  I say this particularly because the overall management of policy and process development in CZ is essentially the job of the Editor-in-Chief.  (That's also why I've involved myself very closely and carefully in the development of this system.)

How it's decided?  Well, we need to have a new set of guidelines that describes the general purviews of the different groups.  This is going to take deep thought, which I don't want to take the time to do right now.  But I can say what the groups are, at least.

• Constabulary: behavioral rules and general user management
• Editorial Council: consequential content policy
• Approval and feedback: editorial initiative devoted to improving and managing our article approval and feedback systems (subgroup of EC)
• Eduzendium (subgroup of EC)
• Recruitment (subgroup of EC)
• Editor-in-Chief and Executive Committee: everything else, including general project management questions
• PR (subgroup of Executive Committee): public relations issues, broadly construed
  

[Larry Sanger]

I was sort of following this from a distance, but decided to make one comment here: it is not a good idea for everything to be loaded onto the Editorial Council and [separately or combined] the Editor in Chief. In my opinion, the Ed. Council should be confined to editorial matters, and not attend to other issues of governance. This means that there is a lacuna: the obvious thing to do would be to restructure the Executive Committee so that it does not "advise the E-i-C" but actually makes policy relating to general management issues.

I realise that this is sort of peripheral to the whole focus here, but it seemed relevant. This debate should also inform your revision of the purpose and structure of the Ed. Council, Larry.

I'm inclined to agree, Martin.  I can't think it through entirely right now, but I can't see any reason off the top of my head why that shouldn't be the case.  Wait, yes I can, one: the Exec. Comm. has a private mailing list.  Well, I better not start thinking about it, or I'll get easily sidetracked.  We do need to settle this soon, but let's finish getting the proposals system and new personnel roles pages set up first.

I sure could use help on the latter, similar to the level of help and development that Robert gave us with [[CZ:Proposals]], by the way: http://en.citizendium.org/wiki/CZ:Proposed_Leadership_Roles

[Larry Sanger]

(New questions)

How, exactly, should the system track status?

This is problematic to me, because we've already had experience with tracking the status of Editorial Council resolutions, and Supten and I can tell you it's not easy, and it's easy to drop the ball.  I can easily see that this is a place where the system could break down: somebody makes a cool proposal; it is put into the queue; it is never heard from again.  If you do that too much, then the proposals system becomes, quite simply, another piece of organizational cruft that does no one good and simply confuses matters.

This is why we simply must have a committed, active, heroic proposals manager.  There is no other way to guarantee that the drop will not be dropped, than if someone (at least one person) is really committed to not dropping the ball.  The E.C. ran smoothly (last year) largely because of Supten's work in this regard.

We must not impose too much on this proposals manager.  It must be work that is both doable as quickly and easily as possible, preferably with help from others, and manages to convey the information that we need to have about proposals.  That raises the question: what info do we need to have about proposals?  What elements of "status" are important to track?

Well, here we go.  The main reason we're tracking status is that we want to know (1) what, generally, needs to be done next (we need to know what actions we need to nudge), (2) whether a nudge is necessary at this point, and (3) of course, whether the proposal is finished.  OK, since we need to know (1) and (2), that means we need to specify, as part of the template, the next item that needs to be done, and we also need a date after which a nudger (no doubt the proposals manager; but perhaps he/she might have help here) gives a nudge.  (And we also need to record that we've given a nudge and when.)

What happens if a proposal driver drops the ball (has failed to drive the proposal forward adequately)?  And how do we determine that he/she has dropped the ball?

Well, this isn't too hard, given the above-described apparatus.  We might say that a proposal is officially "dropped" after someone has been given two nudges, and hasn't taken the next step in that time.  Then we might remove the driver from the driver's seat, and announce that the proposal needs a new driver.  It is put into the overflow queue with a note of who the old driver was, pending the arrival of a new driver.  If a new driver takes up the proposal, it can be moved back into the main queue.

By the way, I suggested earlier that there be a limit on the number of items in a queue.  I think I now disagree with that.  I think all proposals with active drivers should be in an "active queue."  We don't want to discourage drivers from moving forward on them; having a proposal in the queue would be a small badge of honor, after all.

How is it decided what the next step and the due date are?  Basically, the driver should add this information to the proposal.  If it is not added to the proposal, the proposal is placed on a "stalled proposals" page.  Indeed, let's change the name/concept here from "overflow" to "stalled."

Completed steps should be included in the template as well, as a "pat on the back."

Should proposals in [[CZ:Proposals]] queues include discussion/evaluation, and/or links to separate discussion/evaluation pages?

No.  I simply don't see any reason for it.  The purpose of the proposals system is not to evaluate proposals at all, but just to see to it that the entire proposal adoption process moves forward.  Discussion of the proposal belongs elsewhere.

What happens if someone wants to tweak a proposal, and someone else (such as the original proposer) disagrees?  Who decides?

The people involved should negotiate; and they should bear in mind that sometimes (singular) proposals would be better formulated as (multiple choice) issues.  If they can't arrive at a mutually agreeable decision, either a person from the relevant decisionmaking group, or the proposals manager, should be consulted.  The ultimate decisionmaker on the shape of any proposal, at least before it is submitted to a decisionmaking body, will be the Editor-in-Chief.  Once before the decisionmaking body, the body may do whatever they want with it, including amend it.

Are there any constraints at all on who may make what sort of proposal?

No.  Anyone may initially make a proposal.  However, not just anyone may take the lead on, or drive, a proposal.  For example, suppose a very enthusiastic 20-year-old student wants a complicated editorial policy adopted.  That's all well and good.  But the student may not determine the shape of the actual resolution made to the Editorial Council; a Council members should do that.  In other words, just because you propose something, that doesn't give you the right in our system to establish all the policies and process surrounding your general proposal.  The people with the relevant authority make that decision.

Still, if there isn't anyone in the relevant group who wants to take up the proposal, then someone from outside the group may do so.  But if, in order to get a proposal considered by a group, one must be a member of the group (this is the case with the Editorial Council), then one of the steps in "driving" the proposal forward must be: get the proposal to be sponsored by a decisionmaking group member.  And if the driver cannot secure such sponsorship within a reasonable amount of time, then the proposal is considered stalled and is dropped from the active queue.

OK, finally: where do the more lengthy proposals + discussion of them live?

Note that the short, template versions of proposals, the boxed text that goes in the queues, must be linked to another page, which is where all the "action" goes.

I think that, for the sake of simplicity, they should all be subpages of [[CZ:Proposals]].  This even goes for Editorial Council resolutions; it's just that, when a resolution is formally made and numbered, we redirect the CZ:Proposals subpage to the Editorial Council resolution page.  So the first proposal should be [[CZ:Proposals/0001]].

By the way, I just remembered: we need to make a separate category of "group for decisionmaking": individuals.  There are some proposals that we can just let people develop without any permission from anyone.  Therefore, here's another question:

When must a proposal require approval by a group?  Is there any reason why an individual might put a proposal in the proposals system even if it does not require any special approval?

We will leave this up to the judgment of the Proposals Manager(s) and the Editor-in-Chief.  But if any member of the decisionmaking group asks for review and approval, or if there are serious calls for review and approval, then we require review and approval.

Yes, there is a reason why an individual might put a proposal in the system even if it doesn't require any approval: the person is afraid he might drop the ball; or he doesn't want to be its driver (merely its proposer); or he wants reminders and management, to keep him on the ball.

What if a decisionmaking group thinks that they should have a chance to vet a proposal, and the proposal isn't assigned to them?

The ultimate decisionmaker about the venue for decision will be the Editor-in-Chief, until such time as we adopt a Judicial Board; then they might take it up.

Is this system scaleable?  What happens when we've got a million contributors and 100 new Constabulary proposals per day?

Er, yeaaaah...we change the system.

Hey, this is looking awfully complicated.  Are you sure the instructions for the system can still be kept simple?

Yes, because only a few people really need to understand the detailed rules of the system: the Proposals Manager(s) and the Editor-in-Chief.  This means that the basic rules can be distilled to their essentials on an instructions page, while the many details can be shunted to another page.

OK, I think I'm done with my theorizing.  Tomorrow I'll start implementing it, changing the templates, etc., if Robert or someone doesn't do so first (please do, but please also study what I've written above, because it's pretty complicated as you can see).

[Martin Baldwin-Edwards]

This looks pretty good to me, Larry, from a rather quick reading. Sorry I'm not much help at the moment, but I am overloaded with work. The expansion of the EU to 27 countries is simply a nightmare for research and policy advice, and this is just one of the projects that I am responsible for 

[Stephen Ewen]

...it's pretty complicated as you can see.

Big red flag.  Does that not seem to too much have this too-complicated logo on it?