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 <[email protected]> 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 <[email protected]> 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/
