At 22:25 28-07-2013, Dave Crocker wrote:
I've been finding discussion and actions about newcomers far more
interesting this year, than most previous ones. So I think it's
worth pressing on several fronts, to see how we can both accommodate
such folk better, as well as be clear about when and where and how
such accommodation is /and is not/ appropriate.
The keyword in the above is "actions". Some actions do not require
the agreement of the entire IETF. In other words, an action does not
require consensus if it is not mandatory.
Your reply to me, above, lists different types of new folk -- and of
course the list is reasonable and might be useful -- but I didn't
see the actual clarification of what you felt was wrong in the
target text or how you agreed with me an others. So, now you've got
me curious for that detail...
A public discussion can be started with:
(a) I will be listening to your comment.
(b) You must have read X, Y, and Z before you comment.
(c) Be sure that you are not wasting my time when you comment.
I'll argue that (b) and (c) are trying to stop problems before they
happen. (b) looks like the type of thing which ought to be explained
during the orientation. (b) is not a problem caused by remote
participants as it is possible to provide an explanation through the
Jabber room. (c) is intimidating. I would choose (a).
My suggestion is for a 'status' page that gives a brief
summary about the current state of the working group, ideally
listing the current, near-term vector of the work -- what's the
current focus of effort -- and major open issues.
I'll suggest that it be updated after every meeting.
Arguably, this sort of status statement is good to have even without
newcomers, since it forces working groups to face the question of
what progress they are and are not making.
The simpler form might be to update the milestones so that anyone can
read about the work the working group is planning to do and when it
is planning to do it. It also provides information about the work
that the working group has completed.
On the topic of remote participation I'll mention that the current
approach is to open a trouble ticket when there is a problem. A
status web page could provide some visibility about whether the
services are running correctly, whether there is a known problem,
etc. Notifications could be sent to xmpp:hallway@xxxxxxxxxxxxxxx so
that people do not hit the reload button repeatedly.
Regards,
-sm