Subject: RE: Beyond conflict

From: "Hallam-Baker, Phillip" <[email-masked]>
Date: Wed, 12 Oct 2005 09:36:35 -0700

I like Wikis, I also think they have some significant problems. I like
the Wiki text markup functions better for manual entry than HTML. On the
other hand they give even more scope for loonies and trolls.

The point I am trying to make here is that 80% of the list traffic is
being driven by two disciplinary issues. It might help some people's
blood pressure to remember that we are using a strongly sub-optimal
collaboration tool here.

I think we should look at new collaboration tools, for example has
anyone tried using a wiki to maintain an issues list?

This is meant to be a technology organization. If we do not try out new
stuff why should we expect Internet users to? 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Scott W Brim
> Sent: Tuesday, October 11, 2005 11:08 AM
> To: [email-masked]
> Subject: Re: Beyond conflict
> 
> On Mon, Oct 10, 2005 03:17:56PM -0400, Michael StJohns allegedly
> wrote:
> > At 02:43 PM 10/10/2005, you wrote:
> > >Michael StJohns wrote:
> > >>Jabber room dedicated for the specific discussion.
> > >
> > >
> > >im systems do not have threading, nor is it clear how threading 
> > >could/should be done.  --
> > 
> > E.g. Jabber room for discussion on foo, jabber room for 
> discussion on 
> > bar, etc.
> > 
> > The key is that Jabber rooms can be created pretty much on the fly 
> > without requiring subscriptions and have tools such as 
> archiving (e.g. 
> > I can still get the discussion from last ietf on dnsext).
> > 
> > So "Let's take this discussion to [email-masked].  Live 
> > discussion at 11am daily edt, but feel free to place 
> comments at any 
> > time." for example.
> > 
> > I haven't a clue if this will work - but that's a cultural 
> discussion 
> > not a technical discussion best resolved by experimentation.
> 
> I suggest one or more Wikis.  We know the problems of mail.  
> We know the problems of instantaneous "discussion".  In 
> between you have Wikis, which allow time for contemplation 
> before posting, archives with rather interesting 
> non-hierarchical interconnection of posts, no need to 
> create/destroy mailing lists, RSS, etc.
> 
> _______________________________________________
> Ietf mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ietf
> 
> 

_______________________________________________
Ietf mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ietf

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 14 Oct 2005 16:58:11 +0200

> anyone tried using a wiki to maintain an issues list?
Quite a few WGs use issue trackers of various kinds.

The Global Grid Forum uses a web tool based on sourceforge
for Last Call comments (which they call Public Comment). That
of course prevents self-feeding mailstorms.

See http://www.ggf.org/ggf_docs_public.htm

If people like that sort of approach, we should think about it.

    Brian

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Fri, 14 Oct 2005 17:14:00 +0200

> of course prevents self-feeding mailstorms.

the "of course" part being that it's so cumbersome to use that folks don't 
check it that often, so they don't react to others' comments?

mailstorms have their positive sides....

---

From: "JFC (Jefsey) Morfin" <[email-masked]>
Date: Fri, 14 Oct 2005 18:16:52 +0200

At 17:14 14/10/2005, Harald Tveit Alvestrand wrote:
>the "of course" part being that it's so cumbersome to use that folks 
>don't check it that often, so they don't react to others' comments?

agreed.

A few years ago we had a DNSO/GA task force to improve the working 
methods of this now defunct structure. One interesting extremely 
simple  feature we discussed and I implemented positively later on in 
a few cases (for complex private thinking, report preparation) was 
the "position statement link".

The charter and the current status of intended the deliverables are 
documented on a single simple site with a link with all the 
participant pages (could be the IETF WG Page), lurkers do not need to 
have a page. On their page, participants maintain their own 
_different_ positions on the currently discussed topics (when they 
agree with the advancement of the deliverable, they remove their 
position). They can keep archives, historic, back-ground, quotes, links, etc.

The interest is that anyone entering the debate can have a full 
understanding of the pending issues in minutes. And the matters can 
be organised. So you can consider Chapter 17 only, without having to 
read everything.

Also, a consensus is only to reduce the differences between 
propositions (no need to repeat the differences ad nauseam - when you 
update them everyone seens it). In different groups I experimented 
different page formats, reporting tools, etc. From this I am sure: 
the concepts may support many variations, may support many different 
WG styles, make the difference/blocking points plain to everyone, 
help to agree or agree we disagree (people not documenting a position 
on a topic have no reason to interfere), etc. It is very near from a 
wi-ki but far easier to implement, and it permits everyone to be the 
master of his presentation (ppt, jpeg, etc.). Also, position sites 
can be collective. Tools to establish compared position reports can 
be developed, if there is a common format (can be very simple and 
cover only one summary block per topic on each page).

One of the most interesting (disturbing?) "feature" is that everyone 
can assess the competence/ignorance and humility/arrogance of every 
participant. This tends to reduce the debate to the people who have 
real experience, without preventing new suggestions. This also 
permits small groups to form on an issue to work a common position, 
without splitting the working group: the result is put online in 
common - through a specialised link, or to support the position of a 
person, etc. It also permits external guest specialists from a side 
aspect to comment and to be listen to. They have not to follow all 
the debate, just to comment on their own part. Once their 
presentation is agreed, the group can refer to it (or ask for more details).

Experience shown it takes time to start (new concept, it was not a 
real product, people must know how to maintain an HTML page, etc.). 
But afterwards it permits to go much faster, to rise the quality 
standard, etc. and also to support large period of inactivity or of 
separate thinking (experimentation). Also, the "it told you"s which 
were never told do not work. When someone discovers a yet not solved 
problem, he just describes it on his site. Only him can remove it. So 
we are sure we have a consensus. This is not the WG-Chair who orders it.

A good point is that it also simplifies multilingual common work. The 
entries can be crafted by participants. Explanations can be attached 
and reviewed if not understood. Once, I saw opponents reviewing texts 
of their adversaries - just to make sure they understood the 
objection correctly. This can be very simple, quick and rewarding 
(when helping editing, one understand better). Once the only mailing 
was to announce the updated pages (so only the organiser sent mails 
to the list). It could have been automated in any language. Inventing 
a RFC 3683 PR-action is very difficult in such a context.

for what it is worth.

jfc

---

From: Sam Hartman <[email-masked]>
Date: Sun, 16 Oct 2005 16:50:00 -0400

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes: for example
    >> has anyone tried using a wiki to maintain an issues list?
    >> 
    Brian> Quite a few WGs use issue trackers of various kinds.

    Brian> The Global Grid Forum uses a web tool based on sourceforge
    Brian> for Last Call comments (which they call Public
    Brian> Comment). That of course prevents self-feeding mailstorms.

    Brian> See http://www.ggf.org/ggf_docs_public.htm

    Brian> If people like that sort of approach, we should think about
    Brian> it.
I I think that I want multiple views/interfaces to the same data. 

I like email for participating in a last call discussion.  I get to
use my UI; there is a well defined functional interaction protocol
(IMAP, SMTP) for exchanging the information and for allowing me to
thread it, reply to it, handle it offline.  I have a lot invested in
being able to deal with email  well because I get a lot of email.

However email is very annoying for seeing if all the issues have been
dealt with or seeing what the current consensus summary of an issue
is.  A webpage would be great for that.

But if all I had for last call comments was a webpage I'd tend not to
make as many comments or be as active in discussions.

We certainly don't want somethnig as simple as the datatracker.  For
example, discusses are entered in the datatracker.  But we do a
horrible job of tracking the actual discussion that leads of to
resolution of discusses.

I agree we should have better tools.  I would be very skeptical of a
solution that forced everyone into one interaction model.

--Sam

---

From: Henrik Levkowetz <[email-masked]>
Date: Mon, 17 Oct 2005 00:35:32 +0200

Hi Sam,

    I have a design for an issue tracker adapted for IETF use lying
around, but haven't had time to implement it yet.  I think it may
match the requirements you place on a solution in your note below.

The idea is based on my experience when doing issue tracking for the
IASA BCP during December and January nearly a year ago.  Some days
with intensive discussions I spent as much as 5 hours doing cut and
paste from mailing list to issue tracker (RT - a good and competent
issue tracker), and became convinced that there must be a better way.

The idea is based on our way of working, and on the premise that
almost everything needed by an issue tracker is actually already
contained in an email message.  (Subject - reporter - threading
by "In-Reply-To:" header or subject - date - report details...)

The tool could be seen as an merge of a list archive and an issue
tracker.  All issues should be posted to the list, matching the way
we work today.  Adding a few particular keywords (based on Bernard
Aboba's well thought-out template for reporting issues to the EAP
list; http://www.drizzle.com/~aboba/EAP/eapissues.html) to a message
could trigger the automatic creation of an issue, or a document
editor, chair or AD could use the web interface to the list archive
to mark a message or a part of a message as an issue.

Any follow-up messages to the initial message of an issue would be
added to that particular issue unless the chain was explicitly
broken by the document editor, chair or AD.

Similarly, going back and flagging an earlier message as an issue
to be resolved would automatically bring along all of the follow-up
messages into the list of comments on that issue.

Most (all) of the management of the issue tracker side of the
mailing list archive could be handled simply by following up on the
threads on the mailing list, supported by recognition of certain
keywords in the subject line or start of the body (E.g.,
"Text needed:", "Text proposed:", "Issue resolved:"), but management
through a web interface would also be supported.  Information about
status changes done through the web interface would be sent to the
list by the tool.

For most issue trackers, this way of working would seem pretty
roundabout, which probably explains why there isn't such a tool
available (as far as I'm aware).  But for our way of working, I think
it might be just the ticket.

Comments on this idea would be most welcome, either here or on the
[email-masked] list.

Regards,

	Henrik