Proposal of CZ:Proposals

[Robert_W_King]

It actually makes sense to have both but only if you change the setup so that the same information is relayed on each. New threads on the forum should be automatically sent to the maillist. Likewise replies on the mail list should be added into the forum. That way you can choose the medium that suites you but not miss anything.

However, this is all quite academic as nobody seems to use either the maillists or the forums for workgoup stuff. Instead most workgroup level discussion seems to happen on the workgroups talk pages in the wiki itself.

The point is that it could be used for general cz-wiki stuff -OR- workgroup related issues.  Plus, it's easy to track since it could simply be added to your watchlist.  Also, if there's a proposal that gets accepted in a particular workgroup, and it turns out that it's a good standard for a lot of things, then it's easily all in one place for another workgroup to adopt.

Ultimately, it offers the most flexibility with needlessly overcomplicating and distributing everything around.

[Denis Cavanagh]

I think the CZ:Proposals idea is a good one 

[Larry Sanger]

(I'm just now back from EMU!)

I think we should discuss the issue of how to consolidate discussion separately.  (I'd like to point out that we obviously will not be getting rid of Citizendium-L, which is an announcement list.)  What I want to discuss next is how to operate the proposals queue.

Well done to Robert for putting together a proposal template.  We might or might not need to tweak it, but the basic concept is right.

What questions need answering about the proposals queue?  Here are some, with answers.  I'll adapt these answers in filling out the guidelines on the wiki pages.

How is the proposals system to be adopted?

We have no established way of adopting such a thing.  It is an inter-group tool, and so should not be adopted (solely) by the Editorial Council.  (And that is a governance problem: we should have a well-described method in place for this sort of decision; we'll get to it, and building the proposals system will help.)  So I'll simply assess how much support there is, and ask for feedback from the Executive Committee, and (if the support is there) it will be through this ad hoc way considered "official."

What constraints need to be imposed on the design of the system?

There are several.  (1) The system should be as simple as is consistent with its good functioning.  We should not multiply categories, subpages, rating systems, etc., unnecessarily.  (2) The explanation of how it works should be well crafted, brief, and simple, making it easy for Citizens to use and understand, and making it more likely that they feel empowered to participate.

What decisions need to be made explicitly about the system?

• What basic information in a proposal is needed?  Bear in mind it shouldn't be too much...
• What other rules should a proposal follow, or what other basic features should a proposal have?
• 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.
• 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.
• Consider that part of the use of a proposals queue is to allow people to find easily whether a certain idea has been thought about, and what status of work on it is, and whether work seems to be moving forward.  In other words, the system isn't just a governance system in which we get proposals started; it's a high-level project management system, in which we track (again, as simply and straightforwardly as possible) where proposals are.
• Are there any constraints at all on who may make what sort of proposal?
• Other questions?

I'll start answering the above next; then the plan is to transfer this work to [[CZ:Proposals]].

[Robert_W_King]

How is the proposals system to be adopted?

We have no established way of adopting such a thing.  It is an inter-group tool, and so should not be adopted (solely) by the Editorial Council.  (And that is a governance problem: we should have a well-described method in place for this sort of decision; we'll get to it, and building the proposals system will help.)  So I'll simply assess how much support there is, and ask for feedback from the Executive Committee, and (if the support is there) it will be through this ad hoc way considered "official."

However they are adopted, I just created a CZ:Adopted proposals page which might list those which have been accepted after whatever process has gone through, although it could equally exist at CZ:Proposals/Adopted

[Larry Sanger]

Before tackling the above-listed questions, it will be useful to review why the system is necessary, and what its precise function would be.

For one thing, we have too many different venues where we can make proposals.  Here's a list: to me; to my "suggestion box" (which I'll be archiving--if anyone wants to do that for me, and to transfer over the proposals there to CZ:Proposals, that would be great); on these forums; on talk pages; in the Editorial Council; in the Constabulary; in the Executive Committee; sometimes, even on Citizendium-L.  That's part of the problem: we need one place where, if someone adds a proposal, the proposal is officially made, and we as a community commit to responding to it (if only to discard it).

The other problem is that, for whatever reason, too many people feel comfortable making bare proposals but do not seem to feel comfortable taking the next step in making them happen.  I think that's partly because they don't know how to make them happen, but also because they aren't fully persuaded that they won't be overstepping their boundaries if they take the next step.  As a result, only a small number of people have been bold enough to make and drive forward various proposals--especially me.  This constitutes a serious bottleneck.  The system ought to be more bottom-up and open, but to be bottom-up, it needs to be designed a certain way.

A final problem is lack of understanding about how proposals actually are made, and that rank-and-file Citizens can make them, get behind them, and make them happen.

The system should be designed to solve these problems; that's why I originally suggested it.  So what is the function (are the functions) of the system, precisely?

(1) To serve as a single, central location for proposals that people have a shared understanding will lead to action.
(2) To 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.
(3) To explain and clarify to people just how their own proposal can be adopted with a minimum of unnecessary bother and confusion.

Next, the above questions answered.

[Larry Sanger]

How is the proposals system to be adopted?

We have no established way of adopting such a thing.  It is an inter-group tool, and so should not be adopted (solely) by the Editorial Council.  (And that is a governance problem: we should have a well-described method in place for this sort of decision; we'll get to it, and building the proposals system will help.)  So I'll simply assess how much support there is, and ask for feedback from the Executive Committee, and (if the support is there) it will be through this ad hoc way considered "official."

However they are adopted, I just created a CZ:Adopted proposals page which might list those which have been accepted after whatever process has gone through, although it could equally exist at CZ:Proposals/Adopted

No no--I'm not talking about how proposals in general should be adopted, but how the proposals system proposal should be adopted.  We've already got methods for adopting different proposals...

[Larry Sanger]

What basic information in a proposal is needed?  Bear in mind it shouldn't be too much...

Well, again, we must advert back to what the purpose of the system itself is.  There is one thing that the system definitely should not be set up to do, and that is to judge and approve the proposals themselves.  That implies a kind of centralized decisionmaking that the CZ division of powers militates against.

The purpose of the system is project management, not project decisionmaking--there's a big difference--or, in other words, it's all about bookkeeping and cheerleading.

I think it will help for us to distinguish between some very basic types of proposals.  One would be a proposal that a decision be made about some particular question; call these "Issues."  Another would be a proposal that CZ adopt a specific policy or process or take some definite action; call these "Proposals."  Well, I think it makes sense to distinguish Issues from Proposals, and also to treat them slightly differently.  This doesn't necessarily mean they need to be made into different queues.

OK, so for purposes of "bookkeeping and cheerleading" (but not decisionmaking), what needs to be included in the (text of the) proposal itself?  Let's see what Robert has put in so far in the present version of the proposals template: proposal text; justification; prior discussion; and notes.  Well, let's see.  How much of this, and what else, is needed in order to keep track of the proposal and make sure it is intelligently and efficiently considered and, possibly, adopted and acted upon?

The proposal text is obvious, but I would add a proposal title for ease of scanning, and I would limit both title and description under a certain number of words.  The full proposal can be read elsewhere.  (Where, we'll discuss, but this isn't the place for full proposals.  It's the place to get an overview of the whole proposal proposal, with proposals living outside the system, so that the system itself can remain simple and easy to understand.)

As to issues, the title should contain a relatively simple question, and the text of the issue should lay out (briefly) the options that the person is proposing to present as options.

I can think of only one reason to include the justification, and that is to explain why the proposal might appear necessary or beneficial, thereby simply clarifying why the proposal exists at all.  It isn't part of the purpose of the justification section to give a full and complete defense of the proposal.  So, all that justificatory work should be done elsewhere.  And so, again, the number of words allotted to "justification" should be limited.

As to "prior discussion," I would definitely omit "prior" in any case, as any discussion for any non-adopted proposal will potentially be ongoing.  Should we link to discussion at all?  I'm not sure.  Since the full proposal will live elsewhere, and we'd like people to read it before discussing it, why not simply link to the proposal page, wherever it might be?  This strikes me as being ruled out by the "simplest possible system" meta-rule.

That raises the question: where should the full proposals live?  It depends on the area of the proposal.  I'll discuss that later.  But, obviously, the template has to generate a link to the (full) proposal.

A "notes" section?  Sure.

In addition, we might need to add the following:

(1) Assigned decisionmakers.  To discuss.  Will include things like the Editorial Council, the Editor-in-Chief, "whoever shows up," etc.  This is a big topic that we must not quickly gloss over.

(2) Driver.  These are the people who move the proposal from initial conception to consideration by the relevant decisionmakers, whoever they might be.  Anyone can add their names here, as long as they specifically commit to moving the proposal along.  You aren't necessary going to be the driver of a proposal just because you make the proposal.  If you do nothing with it, you should be removed as driver, and something should happen to the proposal.  Moreover, just because you're the driver, that doesn't necessarily mean you get to spell out the details of the policy; that might have to be done by someone else, and so the proposal or issue might turn out looking different from what you originally proposed.  More later on that.

Those are definite.  The following are optional and, for that reason, should be strongly considered not to include:

(3) Status.  Will it help very much for us to have a line that will read (for example) "Initial proposal," "Discussion," "Revision," "Under consideration by decisionmakers," etc.?

(4) Next step.  This could be automatically generated by the data used for "Status."

(5) Urgency.  Yes or no.  Whether it's specifically important that it be done before a specific date or not.

(6) Impact.  Whether, in someone's opinion (?), the impact of the proposal is project-wide and dramatic, or relatively narrow and small in impact.

The last two might be used to rank the order of proposals.  But they probably aren't necessary at all if we just have a queue.  More on that later, too (discussion?).

Anything else?

[Larry Sanger]

'''What other rules should a proposal follow, or what other basic features should a proposal have?'''

Just a few late thoughts on this question--more to come tomorrow or Sunday.  Robert, or whoever, are you interested in rewriting the proposal template with the above in mind?

Robert's made a decent first stab here: http://en.citizendium.org/wiki/CZ:Proposals/Guidelines  Discussion of the template is above.  He makes a good point that the proposals page isn't the place to criticize others or to "stage a coup" (hey, that's the wrong place to stage a coup!  ).

I would give some more specific guidelines, most of which can be placed to one side or on a special page of notes; some of these are "legalistic" details that need to be stated, but which should not get in the way of a clear presentation of what the system is about:

• 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, then it is not a well-formed proposal.
• If a proposal contradicts an existing rule, that fact must be acknowledged, and the proposal must be formulated as an amendment to the rule.
• Proposals in some cases might have to be restated as an issue for the relevant decisionmakers to decide.  For example, if a proposal recommends only that we do X, when there just one or two obvious alternatives, Y and Z, then the proposal should be converted to an issue, asking for a decision between X, Y, and Z.
• We might require certain (to be stated later) minimum categories of information in order to be added to the queue, such as proposal text, and a proposal "driver."
  
• Proposals must not be frivolous; they must not be made only to tell a joke, or to make an ironic statement, etc.  Such proposals will simply be deleted.
• 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.  Making such a proposal will be grounds for warning or removal from the project by the Constabulary.
• Any more?  I'm sure I'm just scratching the surface.  Just bear in mind that this just concerns the content of the proposal itself, not how proposals are handled, etc., or other questions I haven't gotten to yet.

We also need a way to initially vet proposals in keeping with these rules.  I think we should have a proposals page editor or two, who will be able to delete sub-par proposals (or move them to a page for reworking).  How do ya'll think that should work?

And how is the above?  Am I doing all right?

[Stephen Ewen]

What's missing is what DOES NOT require a proposal.  Consider the following.

--someone wants to create a better image gallery template
--someone else wants to create a different image gallery template they think is still better
--three users get together and decide to create a template for sports-related or musician-related catalogs
--two other users get together and think they can do better and create a different template for musician-related catalogs
--a small group gets together and wants to create categories to organize all those templates
--someone decides out of their goodness to create a really nifty "link center" template for group X, so they just make it and say "here, this may be really useful to you, maybe not"
--people of that group decide its great and start to use, then a few notice a few ways it can be improved, create Version 2 of it and say again "here, this may be even more useful to you, maybe not"

That sort of thing. 

I reiterate, surely not every action must be stamped and certified before it happens. Surely it is beneficial for the project to allow people the freedom to just create certain things, and then let emerging common practice "decide" which is best, e.g., (Sam's musician-related template for catalogs is "decided" to be best because more people in practice use it, while Tom's version becomes "deprecated").  Surely if things become too complicated, too many people just won't bother.  This is the sort of thing I mean when I use "the m word".

[Robert_W_King]

A few things:

• I changed "Justification" to "Reasoning" as justification is more of a defensive term, reasoning is a better context for providing a basis, although I could have used "Basis" as well.  (goshdarnit)
• I agree that there are seperate things to which proposals can be made about e.g. community issues vs actionable items and for that I can probably just make a different colored template for.
• The titles for each proposal can be under the subheading, which it is currently.  This seems to be the "natural" way that people have decided to list them (the current four had titles; I did not add them)
• I think the "prior" or "previous/current discussions" section is extremely important because it gives some kind of urgency to the required action without having some kind of indicator in the template to allow someone to falsely increase the priority of an item.  Why is it important?  Because it ultimately shows the number of times an issue has been brought up, clearly with no resolution.  This stresses that it has come up a number of times before, and some kind of conclusion is required.
• Responsibility: on the template I think there should be a place where some designated individuals can indicate that they're handling the issue, specifically if the proposal is about some workgroup or editorial issue.  It empowers someone to take the initiative and say "Yes, I'll handle this."
• Status: this can simply be achevied by changing the color of the proposal or moving it to one of the subpages (not as in the subpage initiative) of the main proposal area.  Update:  I've added a new template, claimproposal that adds a status box.
• "We also need a way to initially vet proposals in keeping with these rules.  I think we should have a proposals page editor or two, who will be able to delete sub-par proposals (or move them to a page for reworking).  How do ya'll think that should work?"  I have thought about just commenting out poorly worded or "messy" proposals.  That way they can be fixed and re-applied.

Other things that I agree with that need no elaboration:

• Proposals must not be frivolous; they must not be made only to tell a joke, or to make an ironic statement, etc.  Such proposals will simply be deleted.
• 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.  Making such a proposal will be grounds for warning or removal from the project by the Constabulary.
• 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, then it is not a well-formed proposal.

Also to cover Stephen's point:

I will modify the guidelines page sometime today to include what "isn't" a proposal.  I think he's right that there are some things which simply do not require that much attention and can be fixed such as (that I can comment on and think of off the top of my head):

* new templates or revision of old templates

[David Goodman]

Well, I thought from the beginning that the structure was too elaborate to follow, and I 'm glad we are finally getting around to consolidation.

[Robert_W_King]

Well, I thought from the beginning that the structure was too elaborate to follow, and I 'm glad we are finally getting around to consolidation.

Can you be more specific?

[Larry Sanger]

Robert, I think your work on the system so far is quite decent, but we will probably also need to change a lot of things.  I'll be making these changes myself, because this is an unusually important process and so it's important that we get it as right as possible.  In short, you're willy-nilly implementing your specific versions of how we should do stuff...I'm not going to support it all.  Moreover, I'll be asking for volunteers from among editors to manage the page and process.  This is all just a heads up.

More in response soon--for now I'm going to go ahead and finish answering my own questions.  

[Robert_W_King]

Robert, I think your work on the system so far is quite decent, but we will probably also need to change a lot of things.  I'll be making these changes myself, because this is an unusually important process and so it's important that we get it as right as possible.  Moreover, I'll be asking for volunteers from among editors to manage the page and process.  That's just a heads up.

More in response soon--for now I'm going to go ahead and finish answering my own questions.  

That's fine, but I don't think it should be any more complex than what I've written so far, otherwise it will end up in the unread abyss of every other help page we've got.

[Larry Sanger]

Robert, I think your work on the system so far is quite decent, but we will probably also need to change a lot of things.  I'll be making these changes myself, because this is an unusually important process and so it's important that we get it as right as possible.  Moreover, I'll be asking for volunteers from among editors to manage the page and process.  That's just a heads up.

More in response soon--for now I'm going to go ahead and finish answering my own questions.  

That's fine, but I don't think it should be any more complex than what I've written so far, otherwise it will end up in the unread abyss of every other help page we've got.

No, Robert, what you have so far is far too complex and confusing; in fact, that's my main complaint about it.