647:-- Instead of allowing the normal unorganised free-for-all of opinions from the start, we started with a few days' fact-finding. All relevant outside data, policies and preceding arguments were collected together in an organised fashion, with full links provided. Commenting on the material was actively dissuaded and removed at this point, with the reminder that everyone would get the opportunity in due time after this phase. Then, when parties were satisfied all relevant material was at hand, discussion was started. (Also see separate section of this page, for more detail.)
630:-- This one worked pretty well, but it was a smaller group of editors. Closing proposals early where there was obviously no consensus for them forming helped focus the discussion. Leaving dead proposals open on the off chance that the opposition could be massively outvoted is an instinct based on the idea that it is indeed a vote. "Kill bad ideas quick" would be a good rule of thumb to aim for, so that they could be reformulated into something that approaches consensus.
375:
page of individual proposals being for developing that proposal, and talk page of the collaborative subpage for general discussion (and the talk page of the initial RFC for discussing individual views). If that's felt to be too much, the relevant talk pages can be redirected, or the collaborative views developed on the one single page. I've specified an implementation that I think will work, but it's the basic idea which is important.
274:
of the collaborative views should have been reached, and they should be closed for editing. Participants can then endorse the stable views. If a stable version can't be identified, views should be split such that competing variations of a view can be endorsed. In this case it will probably be helpful to in some way clearly identify the views as variations.
374:
The root question here is how can we better aggregate individual views in a constructive, debate-enhancing way to enable a well-thought-out and clearly agreed collective decision. Also, I wouldn't characterise my suggestion above as "forking" at all; there is a clear division of labour, with the talk
449:
No rebuttal was the idea behind the traditional RFC of statement-endorse with no oppose sections. What we see is that if someone is upset enough then oppose sections get added anyway. If people had "clerked" the oppose sections on the BLP RFC to the talk page, then there would have probably been a
322:
I propose a RFC so that we can discuss the ramifications of this RFC :-P More seriously, the consensus-based style of decision breaks down as the number of discussants becomes large. We more or less implicitly recognize this, what with elections for ArbCom, RfA, etc. I think it's not unreasonable to
233:
Problem: Whilst
Knowledge is based on collaboration in mainspace, RFCs are based on views expressed by individual editors. This leads to confusion as RFCs grow; the big picture is lost as overlapping and partially contradictory individual views proliferate. Clear outcomes become hard to achieve, and
147:
The idea behind "kill bad ideas quick" is that if an idea is meeting significant early opposition, the chance that it reflects consensus is almost nil. It should be easy to withdraw that proposal and propose a new one that might reflect consensus. The process should support this kind of iteration.
273:
4. Since the collaborative views evolve in a way that individual ones don't, endorsements of these may be affected; people may endorse something they later wish not to, or hold off endorsing to see how it goes. So some time before the RFC closes (eg after 3 weeks, with 1 week left), stable versions
289:
How meta. I like the idea of collaborative statements for RfCs, we should take advantage of the fact that we are a wiki more often in our discussions (I suggested it before for AfD). I don't think they should be made on separate pages, the problem with both the BLP RfC and the CDA RfC was too much
278:
This sounds a bit complicated, but it isn't really. The apparent complication, such as it is, arises from trying to precisely describe an unfamiliar process which should be pretty obvious in use because it structures discussion using tools and techniques which are very familiar from elsewhere. The
486:
we had a perennial request to move the article from Kiev to Kyiv. When this was raised for the umpteenth time (with no significant new evidence or new argument), to save us the normal fortnight-long rehash of exactly the same material, we decided to try out a new decision-making process - and it
204:
This is a perfect illustration of the way
Knowledge has everything ass-backwards. The point of "consensus" is to make sure that minorities are not trampled by majorities. Instead, Knowledge uses "consensus" as a tool for crushing dissent, unorthodoxy, and unpopular minorities. And this is why
490:
Instead of allowing the normal unorganised free-for-all of opinions from the start, we started with a few days' fact-finding. All relevant outside data, policies and preceding arguments were collected together in an organised fashion, with full links provided. Commenting on the material was
259:. This gives each view its own talk page and page history - familiar tools that then become more useful. Care would need to be taken not to split discussion too much - some splitting will be helpful, but not too much. The talk page of the main collaborative views subpage,
384:
Thanks. If something like what you propose were to happen, one thing that would make more sense to me would be to make it to "sides" of the same place -- the discussion on the talk page, and the other part on the project page. (Forgot sig earlier.)
251:
a. This page would seek to develop a number of different views, combining the views of different individual editors. Each view can be edited by anyone in a constructive way. The total number of views should be kept as low as possible and as high as
491:
actively dissuaded and removed at this point, with the reminder that everyone would get the opportunity in due time after this phase. Then, when parties were satisfied all relevant material was at hand, discussion was started.
279:
only tricky part is the endorsements; it would need to be seen in practice how hard that it is; but it's basically a solvable problem, whilst the forest of discussion that arises from current Large RFCs is not.
309:
Yes, it's a risk. But if the splitting is well-structured (unlike the RFCs you mention), the risk is less, and may be worth it. Hard to know without actually trying something in that direction.
564:
417:
I hope you are not seriously suggesting that massive and complicated voting is a good way to solve anything in particular. That
Ireland mess was not something that should be repeated.
432:
348:
I agree that the BLP RFC is a mess, and that making sections for opinions of different people is not the best way. But I think forking is counterproductive. ... The idea behind
627:
524:
Overall I believe that a mid-term collation and distillation of arguments is no bad thing, but I believe that initialising the RfC in a manner similar to that we did at
331:
should probably be put to some kind of vote. I note that this more or less seems to be our practice, although the framing of our de facto votes could use improvement.
513:
comments were generally shorter, because of the easy reference to the evidence and previous arguments - the bane of the popular RfC is the sheer volume of text.
543:
That makes a lot of sense. It won't be always exactly applicable, but the idea of planning and following the plan overall is widely applicable.
101:"Fail quickly", that is, discard ideas with significant opposition so that they can be replaced with a more refined version or a compromise.
610:
659:
But I think the idea of "statement -- endorse" is not generally applicable. For one thing, it gives little support to brainstorming.
528:
could help keep the discussion along more focused lines right from the outset. A combination of the two ideas might work very well.
356:. ... One point is that I think the root question is important, and sometimes that is overlooked. What is the root question here?
34:
is a notable recent example illustrating the need to improve the workings of RFC on issues that involve largescale participation.
435:
statement of opinions was easy to understand and didn't turn into a massive super long discussion thread. The voting was a joke
349:
504:
the important matters of discussion were obvious from evidence collected, so the discussion was focussed right from the outset
501:
it was very easy for any closer to identify and ignore specious arguments and rhetoric not actually based on the facts at hand
138:
17:
507:
old arguments were not rehashed - they were already written down, with explanation of why they were supported or rejected
299:
668:
49:
Reinforces the idea that an editor must choose a position and then defend it, rather than working toward consensus
510:
more time was taken to consider the evidence and make a nuanced, stronger case rather than make reflex judgements
260:
256:
245:
353:
291:
244:
2. At some point, if things become complicated enough (they won't always), someone may split off a subpage:
210:
591:
255:
b. It will be helpful to have each collaborative view on its own subpage, with the view transcluded into
195:
533:
126:
237:
Solution: One way to improve "Large RFCs" (TM) would be to split them in two in the following way.
664:
618:
572:
548:
390:
361:
352:
was good, but it seems like that didn't get off the ground. ... I had started to start a page on
339:
206:
167:
134:
587:
290:
splitting and discussion of discussion of discussion, which leads most editors to drift away.
122:
How can you know quickly something should be killed? Sometimes pushing boundaries is useful.
644:
518:
440:
408:
400:
191:
61:
Self-reinforcing -- for example, this *can* happen when asking whether there is a consensus.
31:
639:
622:
595:
576:
552:
537:
459:
444:
426:
412:
394:
379:
365:
341:
313:
304:
283:
214:
199:
185:
171:
157:
529:
635:
455:
422:
181:
153:
660:
614:
568:
544:
386:
357:
333:
163:
130:
98:
Consider renaming from "Request for
Comment," maybe to "Request for Discussion," etc.
27:
498:
arguments were focused on specific points of evidence rather than general opinions
268:
3. Both pages develop in parallel; new individual views may continue to be added.
436:
404:
205:
Knowledge has a reputation for being a thuggish clique of malevolent
Trekkies.
376:
310:
280:
631:
483:
451:
418:
177:
149:
92:
Visible, clear, concise and neutral summary for newcomers to the discussion.
30:
concerns how
Knowledge's Requests for Comments (RFCs) can be improved. The
83:
Clear separation of what goes on project page and what goes on talk page.
162:
How about changing "bad ideas" to "ideas with negligible support"?
104:
An iterative process instead of trying to solve everything at once.
525:
494:
Why did this work better? I believe for the following reasons:
89:
Don't !vote too early; allow for brainstorming and deliberation.
241:
1. Individual views are initially expressed in the usual way.
55:
Lack of clarity or agreement on the purpose of a specific RFC
565:
Knowledge:Requests for comment/Biographies of living people
64:
Proposals unlikely to attain consensus remain on the table
656:
I don't understand the thinking behind "no rebuttal."
628:
Wikipedia_talk:Username_policy/Blatant_Promotion_RfC
652:Miscellaneous, or haven't thought of a better name
58:Discussion on both talk page and project page.
8:
234:discussion is lost in favour of (!)voting.
46:Listing of viewpoints by individual names.
148:(Promoted to subsection for discussion)
651:
95:Archiving guidelines. Regular archiving.
478:Planning from the outset - a case study
110:Look for and work toward common ground.
567:and some directly-related discussions
263:should be used for general discussion.
113:Look for ways to trade off, negotiate.
354:"how to hold an effective discussion"
7:
611:Knowledge:Community de-adminship/RfC
67:Encourages the formation of factions
517:To see this process in action, see
24:
399:I think the model layout out at
350:Knowledge:Community Facilitation
327:but actual controversial policy
41:Problems with current practices
52:Non-neutral opening statements
18:Knowledge:Requests for comment
1:
487:worked really rather well.
80:Moderation or facilitation.
684:
669:00:30, 15 March 2010 (UTC)
640:20:08, 10 March 2010 (UTC)
460:00:10, 15 March 2010 (UTC)
445:18:54, 14 March 2010 (UTC)
427:13:46, 12 March 2010 (UTC)
413:16:21, 10 March 2010 (UTC)
215:07:38, 31 March 2010 (UTC)
200:13:28, 28 March 2010 (UTC)
186:16:56, 11 March 2010 (UTC)
172:14:53, 11 March 2010 (UTC)
158:13:27, 11 March 2010 (UTC)
623:23:20, 4 March 2010 (UTC)
596:17:07, 7 March 2010 (UTC)
577:23:20, 4 March 2010 (UTC)
553:21:31, 5 March 2010 (UTC)
538:16:47, 5 March 2010 (UTC)
395:17:09, 7 March 2010 (UTC)
380:12:15, 4 March 2010 (UTC)
366:01:53, 4 March 2010 (UTC)
342:18:56, 3 March 2010 (UTC)
314:22:24, 3 March 2010 (UTC)
305:01:15, 3 March 2010 (UTC)
284:19:16, 2 March 2010 (UTC)
261:RFC X/collaborative views
257:RFC X/collaborative views
246:RFC X/collaborative views
107:"Requests for moderator"?
190:I like this idea. --
118:Kill Bad ideas quick?
77:Get at root question.
323:use RFCs to solicit
645:Kiev naming dispute
450:lot of screaming.
229:Collaborative Views
86:Frequent summaries.
28:Request for Comment
338:
72:Possible solutions
598:
332:
143:
129:comment added by
675:
585:
336:
302:
298:
294:
142:
123:
683:
682:
678:
677:
676:
674:
673:
672:
654:
607:
561:
480:
334:
300:
296:
292:
231:
124:
120:
74:
43:
22:
21:
20:
12:
11:
5:
681:
679:
653:
650:
649:
648:
642:
625:
606:
603:
602:
601:
600:
599:
580:
579:
560:
557:
556:
555:
515:
514:
511:
508:
505:
502:
499:
479:
476:
475:
474:
473:
472:
471:
470:
469:
468:
467:
466:
465:
464:
463:
462:
403:worked well .
369:
368:
345:
344:
319:
318:
317:
316:
276:
275:
270:
269:
266:
265:
264:
253:
242:
230:
227:
226:
225:
224:
223:
222:
221:
220:
219:
218:
217:
176:Fine with me.
119:
116:
115:
114:
111:
108:
105:
102:
99:
96:
93:
90:
87:
84:
81:
78:
73:
70:
69:
68:
65:
62:
59:
56:
53:
50:
47:
42:
39:
37:
23:
15:
14:
13:
10:
9:
6:
4:
3:
2:
680:
671:
670:
666:
662:
657:
646:
643:
641:
637:
633:
629:
626:
624:
620:
616:
612:
609:
608:
605:Good examples
604:
597:
593:
589:
584:
583:
582:
581:
578:
574:
570:
566:
563:
562:
558:
554:
550:
546:
542:
541:
540:
539:
535:
531:
527:
522:
520:
512:
509:
506:
503:
500:
497:
496:
495:
492:
488:
485:
477:
461:
457:
453:
448:
447:
446:
442:
438:
434:
430:
429:
428:
424:
420:
416:
415:
414:
410:
406:
402:
398:
397:
396:
392:
388:
383:
382:
381:
378:
373:
372:
371:
370:
367:
363:
359:
355:
351:
347:
346:
343:
340:
337:
330:
326:
321:
320:
315:
312:
308:
307:
306:
303:
295:
288:
287:
286:
285:
282:
272:
271:
267:
262:
258:
254:
250:
249:
247:
243:
240:
239:
238:
235:
228:
216:
212:
208:
207:SmashTheState
203:
202:
201:
197:
193:
189:
188:
187:
183:
179:
175:
174:
173:
169:
165:
161:
160:
159:
155:
151:
146:
145:
144:
140:
136:
132:
128:
117:
112:
109:
106:
103:
100:
97:
94:
91:
88:
85:
82:
79:
76:
75:
71:
66:
63:
60:
57:
54:
51:
48:
45:
44:
40:
38:
35:
33:
29:
19:
658:
655:
588:Calliopejen1
586:No kidding.
559:Bad examples
523:
519:this archive
516:
493:
489:
481:
431:I meant the
328:
324:
277:
236:
232:
125:— Preceding
121:
36:
25:
433:no rebuttal
192:Eraserhead1
530:Knepflerle
252:necessary.
484:Talk:Kiev
401:WP:IECOLL
329:proposals
661:Maurreen
615:Maurreen
569:Maurreen
545:Maurreen
387:Maurreen
358:Maurreen
325:comment,
164:Maurreen
139:contribs
131:Maurreen
127:unsigned
301:Windows
32:BLP RFC
437:Gnevin
405:Gnevin
293:Fences
377:Rd232
311:Rd232
297:&
281:Rd232
198:: -->
26:This
16:<
665:talk
636:talk
632:Gigs
619:talk
613:?
592:talk
573:talk
549:talk
534:talk
526:Kiev
456:talk
452:Gigs
441:talk
423:talk
419:Gigs
409:talk
391:talk
362:talk
211:talk
196:talk
194:<
182:talk
178:Gigs
168:talk
154:talk
150:Gigs
135:talk
482:At
335:Ray
667:)
638:)
621:)
594:)
575:)
551:)
536:)
521:.
458:)
443:)
425:)
411:)
393:)
364:)
248:.
213:)
184:)
170:)
156:)
141:)
137:•
663:(
634:(
617:(
590:(
571:(
547:(
532:(
454:(
439:(
421:(
407:(
389:(
360:(
209:(
180:(
166:(
152:(
133:(
Text is available under the Creative Commons Attribution-ShareAlike License. Additional terms may apply.