All of this is sensible and good and I hope it happens as soon as possible.
The only group that should be allowed to have a hidden tracker/list is,
perhaps, the AB, and I question even that sometimes. Member-only space is a
bug. In fact, new groups (to my mind) shouldn't be given the option of
having member-only space systems except by application and an explicit
exemption.
Thanks for proposing this, Steve.
Regards
On Wed, Apr 8, 2015 at 2:09 AM, Steve Faulkner <faulkner.steve@gmail.com>
wrote:
> Hi all,
>
> I know some of these have been raised and are 'in process', but the
> process appears to be moving slowly.
>
> The following are some suggestions that I think would provide easier
> collaboration between the PF and other working groups and contributors at
> the W3C. Note: these suggestions are personal and are not intended to
> represent the views of my employer
>
> Public-PF mailing list [1]: allow non PF members to post to the list. We
> have had situations in the past where members of the TAG (and other working
> groups) have been unable to respond to technical discussion occuring on the
> public PF list. This has lead to loss of technical input on important
> accessibility related developments.
>
> PF issue tracker [2]: Allow anyone to read the issue tracker if the work
> of the group occurs in public space there is no need to have the issue
> tracker in member only space. Anybody that is not a member of the PF who
> wants to follow a particular issue cannot currently, this is an impedement
> to collaboration and development.
>
> Recommend the primary method of public & inter WG comment be via bugs
> filed on the various sepcifications, this makes tracking and responding to
> technical issues raised easier for the people doing the technical work.
>
> WAI-liason list [3]: This list appears to consist primarliy of responses
> to PF comments on other WG specifications (which reside in the public
> space), yet this list is in member only space, it does not make sense.
>
> PF meeting minutes: remove the unecessary step of scrubbing the minutes
> and only making them public after a preiod of time, it is in general a
> waste of WG member and W3C staff time. If on the rare occasion the meetings
> cotain sensitive information ask those at the meeting if they request an
> opportunity to scrub prior to release.
>
> Move all specs produced by PF to the 2014 process [4]
>
> Take advantage of the new W3C publishing tools [5] that are being made
> avialable, these tools can vastly reduce the amound of time spec editors
> and w3c staff have to spend in producing working drafts.
>
> De-politicise the publication process, I have experienced on a number of
> occasions, the situation where specs i work on have been held up due to
> backroom wrangling even though there has been clear public member consensus
> to publish. Heartbeat publications in particular should be as painless and
> beurocracy free as possible, this will free up time for all involved.
>
> I am a PF member but largely work outside of the PF space because other
> working groups allow me to get on with the technical work without undue
> constraints.
>
>
> [1] https://lists.w3.org/Archives/Public/public-pfwg/
> [2] https://www.w3.org/WAI/PF/Group/track/
> [3] https://lists.w3.org/Archives/Member/wai-liaison/
> [4] http://www.w3.org/2014/Process-20140801/
> [5] https://lists.w3.org/Archives/Public/spec-prod/2015JanMar/0026.html
> --
>
> Regards
>
> SteveF
> HTML 5.1 <http://www.w3.org/html/wg/drafts/html/master/>
>