W3C home > Mailing lists > Public > public-html@w3.org > June 2007

Re: How to productively contribute

From: Ian Hickson <ian@hixie.ch>
Date: Wed, 27 Jun 2007 20:53:02 +0000 (UTC)
To: Robert Burns <rob@robburns.com>
Cc: public-html@w3.org
Message-ID: <Pine.LNX.4.64.0706272042080.14519@dhalsim.dreamhost.com>

On Wed, 27 Jun 2007, Robert Burns wrote:
> 
> Again, this is the catch 22.  Each of us raising our concerns here are 
> not getting responses that could even begin to serve as the other side 
> of the argument so that we can write wiki articles that actually record 
> "the points put forward by both sides". In other words we're not getting 
> the other side from this discussion

There shouldn't be "sides". If there is a feature or use case that the 
spec doesn't handle well, then research the use cases, come up with 
various ways to solve it, figure out the pros and cons of the various 
proposals, and then document everything on the wiki. You shouldn't be so 
attached to an idea that you can't think of other ideas, or so attached to 
an idea that you can't see its disadvantages. You shouldn't need someone 
else presenting another "side" of the "argument" to address an issue.

In any case, if it turns out that you indeed are so blinded by you 
opinions that you can't do an objective job, I'm sure other people in the 
working group will balance out the wiki page for that set of use cases and 
it'll be neutral in the end. So just pretend you're neutral and go ahead. 
(Though if you think there might be a chance you haven't been able to 
become objective enough, then make a note of that on the wiki page.)

The following process can help make one more objective:

   1. Describe the problem you are trying to solve, without any reference 
      to any possible solutions.

   2. Try to determine the root _cause_ of the problem. Is there another 
      problem underlying what you want to solve? In that case, return to 
      step 1, but with this new problem instead.

   3. Describe several possible solutions to the final underlying problem, 
      including careful reasoning for how it solves the underlying 
      problem.

   4. Review each of those solutions in light of how they solve the 
      original problem.

Post the results of your research to the mailing list so that people can 
review it and so that you can refer to an e-mail from the wiki. (That's 
how you satisfy the "no original research on the wiki" rule.)

http://lists.w3.org/Archives/Public/public-html/2007Jun/0863.html
http://lists.w3.org/Archives/Public/public-html/2007Jun/0003.html   

-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'
Received on Wednesday, 27 June 2007 20:53:16 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:01 GMT