Thread Subject: Re: Recommendation:Communications TaskForceConference Call
This archival content is maintained by WebAIM and NCDAE on behalf of TEITAC and the U.S. Access Board . Additional details on the updates to section 508 and section 255 can be found at the Access Board web site.
From: Andi Snow-Weaver
Date: Thu, Oct 12 2006 2:36 PM
- Return to this mailing list's archives
- View all messages in this thread
- Next message in thread: Bailey Bruce: "Re: Recommendation:CommunicationsTaskForceConferenceCall"
- Previous message in thread: mike paciello: "Re: FW:Recommendation:CommunicationsTaskForceConferenceCall"
- Messages sorted by: Author | Thread | Date
For your call today, here are my thoughts about some of the issues:
On subcommittee "membership" vs. mailing list subscribers...
I really wasn't planning on trying to maintain a list of "members" for the
SW and Web subcommittee. I had just assumed that anyone who signs up for
the mailing list is a subcommittee member because these are open to
everyone and there were no instructions for the public other than signing
up for the mailing list. And since the only requirement being discussed for
becoming a member is sending an e-mail to the convenor or co-chairs, it
doesn't seem like it is worth the trouble it will take to administer a
distinction. Anyone who gets denied privileges for not having declared
themselves a member will just declare themselves a member so what have we
Standards groups have membership requirements - some you have to pay to
join, some you can be invited to join as an expert, some you have to attend
a certain number of meetings to be a member in good standing, etc. But
since we don't have that here, it's basically a free for all so why bother
with the extra work?
As to the wiki editing....
My wiki experience is limited to smaller groups than what we are dealing
with here. It would be nice if we could restrict the editing somehow -
subcommittees should decide that for themselves though, not this group.
Co-chairs may not have the technical skills or time to do it but others on
the subcommittee may. But it sounds like it is either not possible to
restrict the editing capabilities or it would be a huge amount of work. So
my suggestion would be that we should just see how it goes. If there are no
problems, then we won't have done unnecessary work. If there are problems,
then we will have to decide how to address them.
On a speaker queue management tool that is integrated with the conference
call bridge ....
This is a luxury that I have grown used to with WCAG. Our meetings contain
much fewer people than have signed up for the SW and Web subcommittee and
until we got Zakim, RRSAgent, and the survey tool, our meetings were not
productive at all. (No reflection on the chairs Gregg :-) )
But if we can't do it, then we can't do it. Can we make it a rule that if
you want to speak, you have to access the Internet to get on the queue? I
think we will take a lot of heat for that. One alternative I guess is for
meeting chairs to pause periodically and ask if anyone without Internet
access wants to get on the queue. The other alternative is that we could
conduct all discussions via e-mail and hold only face to face "meetings" of
the subcommittee either just before or just after the TEITAC meetings.
There seems to be some criticism of the way we have been doing this. We
were all told to "go for it" so we did. I proposed to the SW and Web
subcommittee that we try to close on that topic via e-mail and noone
objected. My interpretation of the protocols was that the subcommittee
could decide to operate that way. I will reiterate Jim Tobias' point here
about working asynchronously. Where we can, we should be encouraged to make
decisions via mailing list discussions. The telephone meetings are just not
going to be that productive with so many people. The co-chair thing seemed
like such an easy one to close on since there weren't a lot of volunteers -
actually there weren't any other than the proposed ones that I know of.
- Next message in Thread: Bailey Bruce: "Re: Recommendation:CommunicationsTaskForceConferenceCall"
- Previous message in Thread: mike paciello: "Re: FW:Recommendation:CommunicationsTaskForceConferenceCall"