Subject: Re: Wikis for RFCs

From: Yaron Sheffer <[email-masked]>
Date: Sun, 18 Sep 2011 00:37:14 +0300

Like Keith, I believe we can benefit a lot from users being able to 
freely annotate RFCs with implementation notes, corrections and even 
opinions ("this protocol option sucks!").

But I also tend to agree with Joel that the wiki format is inappropriate 
for this purpose, because if people are allowed to change one other's 
comments, we are very likely to repeat the WG discussion, but without 
the processes and incentives that enable us to eventually achieve 
consensus. So I am not as optimistic as Keith about the wiki format 
leading to a status quo. The same people who would argue their point 
forever on a mailing list would just keep editing and re-editing the 
wiki page.

I think the Annotated CPAN example ( http://www.annocpan.org/) is near 
perfect for our needs:

- The main text is visually distinguished from the annotations.
- Annotations are visually near the relevant text, rather than appended 
at the end.
- The main text cannot be changed.
- Annotations can be freely added by anybody, it is trivial to open an 
account.
- Users are identified but with no strong authentication.
- One user can comment on another user's comment, but cannot change it.
- There is some moderation behind the scenes (I haven't studied it, but 
it's essential in order to avoid spam).
- There's an average of 1-2 comments a day, so a small number of 
moderators can handle the traffic.

Thanks,
     Yaron

---

From: Keith Moore <[email-masked]>
Date: Sat, 17 Sep 2011 18:49:10 -0400

On Sep 17, 2011, at 5:37 PM, Yaron Sheffer wrote:

> Like Keith, I believe we can benefit a lot from users being able to freely annotate RFCs with implementation notes, corrections and even opinions ("this protocol option sucks!").
> 
> But I also tend to agree with Joel that the wiki format is inappropriate for this purpose, because if people are allowed to change one other's comments, we are very likely to repeat the WG discussion, but without the processes and incentives that enable us to eventually achieve consensus. So I am not as optimistic as Keith about the wiki format leading to a status quo. The same people who would argue their point forever on a mailing list would just keep editing and re-editing the wiki page.

Maybe a workable compromise would be to let people re-edit their previous contributions.   Though I'm also about the tendency for large numbers of people to submit irrelevant material.  I think that some sort of moderation might be in order, which begs the question - who should do the moderation?   Slashdot-style moderation, at least, doesn't seem to work well - it favors those who comment early rather than those who submit the best comments.  What you want to do is favor the contributions that summarize an issue and/or its resolution fairly, clearly, and succinctly; and then make the set of comments that do this, and cover the more important issues associated with an RFC, the ones that are the most visible.

> I think the Annotated CPAN example ( http://www.annocpan.org/) is near perfect for our needs:
> 
> - Annotations are visually near the relevant text, rather than appended at the end.
> - Annotations can be freely added by anybody, it is trivial to open an account.
> - There is some moderation behind the scenes (I haven't studied it, but it's essential in order to avoid spam).
> - There's an average of 1-2 comments a day, so a small number of moderators can handle the traffic.

As a starting point, this might not be too bad, especially if the code is available and can be adapted (even if it is written in Perl, sigh).   Though I think that anything of this nature is going to have to adapt over time as experience with it is gained.

Keith

---

From: hector <[email-masked]>
Date: Sat, 17 Sep 2011 20:44:25 -0400

> As a starting point, this might not be too bad, especially if the code is available and can be adapted (even if it is written in Perl, sigh).   Though I think that anything of this nature is going…

+1.

The thing is that this is all deja-vu.  Consider, we are talking about 
professional collaboration and there are many tools that help in this 
area which in short, emulated the older "red-lining" ideas of getting 
comments.  Geez, I recall when we have a in/box box on our desktop and 
each morning new docs come in and others you were done red-lining went 
out.  Or you had a distribution list attached to it, and you crossed 
your name out and the next person on the list is the one you sneaker 
net the document to.

For our product, it started as online only, then slowly the users 
spread out, to offline, using POP3 then mailing list. At least with 
Exchange, NNTP and IMAP you were still online and single sourcing the 
data.  Today, we still constantly battle trying to single source the 
offline with online.  Something other vendors eventually learned too - 
i.e. Google.

So with the IETF/IESG, you will have similar issues as well:

    - Initial I-D collaboration
    - Any WG mailing list collaboration
    - Any IETF/IETF PS preview collaboration
    - Any IETF/IETF LAST CALL collaboration
    - Any IETF/IETF TS collaboration

My suggestion to first framework this with the I-D as an 
experimentation.  I get my start with the I-D submissions and that 
email can have an URL to some site where we can begin the 
collaboration. for example,  like this one that came in at 3:20pm EST 
today with this URL

     http://www.ietf.org/id/draft-ietf-hybi-thewebsocketprotocol-15.txt

changing it to:

     http://tools.ietf.org/html/draft-ietf-hybi-thewebsocketprotocol-15

takes you to a more interesting page (IMO).

I should be able to see all current comments at the bottom and also 
add a comment, all nicely displayed at the bottom.

I agree with you that a commenter should be able to EDIT, DELETE its 
own comment but not others, only the AUTHOR or some other "sysop" can 
have that level of alteration.  A history is needed though so that 
people can see where/why changes/deletions were made.

Here is one idea for Fred Baker:

I would donate our own package which does still continue to offer all 
the input portals we have today, but its windows based, and there are 
other simpler web based only packages that is 100% open source.

Take an existing open source CMS package with a "Topical" framework, 
i.e. like PHPBBS or the very simple PHP package like SMF from 
http://www.simplemachines.org/smf. This last one is pretty flexible, 
simple and should work under any OS box.

For each new I-D, automatically added as a new TOPIC where users can 
follow up and in this topic/blog style format.

A CMS package is all that is needed that offers easy

   - User/Group profiles
   - Calendaring
   - voting and polling
   - Public vs Private messaging
   - EMAIL, Mailing list integration

--