W3C home > Mailing lists > Public > www-archive@w3.org > July 2014

Re: Is the TAG structure harmful? [Was: Fwd: Forced Resignation]

From: Mark Nottingham <mnot@mnot.net>
Date: Tue, 1 Jul 2014 11:54:03 +1000
Cc: Robin Berjon <robin@w3.org>, Arthur Barstow <art.barstow@gmail.com>, "www-tag@w3.org" <www-tag@w3.org>, "www-archive@w3.org" <www-archive@w3.org>
Message-Id: <84395746-4CA2-46AD-9269-6DA4F95403BE@mnot.net>
To: Tim Bray <tbray@textuality.com>
In a similar situation, the fact that my fellow BEA employee David Orchard was making excellent contributions as a TAG member put me in the position of not being able to do so for several years.

I found other ways to contribute, but it did seem very arbitrary. I'm not sure that opening up the TAG as a WG is the most productive thing to do, since it benefits from small size and focus, but re-examining some of the rules does make sense; after all, if you trust someone to be a contributor to the Web architecture, surely you trust them to know the difference between company interests and the Webs'?

Regards,


On 1 Jul 2014, at 2:21 am, Tim Bray <tbray@textuality.com> wrote:

> [Disclosure]: Ten years ago, I was a TBL appointee to the TAG and took a job with Sun; there was another Sun employee already there (elected I think), so I resigned.
> 
> I think that in the W3C affiliation matters by definition, and I think the policy that limits members to one per employer is basically sensible.  I could see an exception in the case where the membership elected two members in full knowledge they share an employer.
> 
> 
> On Mon, Jun 30, 2014 at 8:13 AM, Robin Berjon <robin@w3.org> wrote:
> Hi Art,
> 
> 
> On 30/06/2014 16:50 , Arthur Barstow wrote:
> [ Bcc public-w3process ]
> 
> On the one hand, as long as some set of TAG participants are elected by
> Members, I suspect some see (marginal?) value in limiting the number of
> participants from an organization. OTOH, I think Consortium processes
> actually retard the growth of the Web when those processes prohibit or
> limit willing and capable people from directly contributing to Web
> standards.
> 
> I won't deny that you bring up good points here, but I think it would be valuable to keep this discussion focused on this specific issue (though opening up other thread for the other issues is certainly an option).
> 
> The rule in question is small and simple, and altering it in the Process is a rather straightforward, well-defined change. I think that it would be beneficial for the AB to get into the habit of making such small, well-defined changes to the Process on a regular basis (whenever required).
> 
> The alternative is the sort of paralysis incurred by boiling the ocean. Again, I don't dispute the validity of your other points, but if this turns into a "Hey, let's fix the TAG!" project we won't see a change for 2-5 years.
> 
> A well-functioning organisation should be able to go through those steps in under two months (mostly accounting for a 4 week voting period):
> 
>   1. Hey look, we have a problem with losing the very scarce resource of quality contributors; happened twice in two years (and has happened before, e.g Norm).
>   2. Here is a five-line change to the Process document to fix the issue (presumably from the AB or the Process CG).
>   3. AC votes to accept or reject after a discussion period. The WBS poll can include the option to apply the change to the current roster.
>   4. On to next issue!
> 
> This would allow you to take up your other change proposals on similar grounds (though I understand that switching the organisation could make this change moot).
> 
> I would contend that an organisation that can't fix a well-defined, well-scoped, small problem (or conversely decide that it isn't a problem and refuse the fix) inside of two months is dysfunctional.
> 
> -- 
> Robin Berjon - http://berjon.com/ - @robinberjon
> 
> 
> 
> 
> -- 
> - Tim Bray (If you’d like to send me a private message, see https://keybase.io/timbray)

--
Mark Nottingham   https://www.mnot.net/
Received on Tuesday, 1 July 2014 01:54:40 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 7 January 2015 14:44:33 UTC