Re: How to productively contribute

On Wed, 27 Jun 2007, Robert Burns wrote:
>
> > Ideally, though, there would not be any "sides", we would just work 
> > together towards a common goal.
> 
> I think that would be great if it were true. However, a read through the 
> email list will reveal that there are sides.

I agree. My original e-mail in this thread was intended to point out the 
futility of these discussions, and to try and encourage a more productive, 
rational, approach. You (Rob) seem to have been the only one to pick up on 
this, sadly. :-(


> There are cases where I'm having a very hard time coming up with cons 
> and I turn to the email list to help with that. Unfortunately, the 
> responses are often flippant or don't take the time to even understand 
> the proposal. Should I simply leave cons out of the wiki page for that 
> particular issue or link to flippant email responses (sometimes these 
> come off-list).

Both. Link to all e-mails on the issue, whether flippant or not. Include 
as much detail in the wiki page as you can. If you are aware that there 
are problems (because someone has said so) but you have no idea what they 
are (because you don't have the first clue what they were talking about 
when they replied) then say that: "con: something described in an e-mail 
by Mr A. N. Other (unclear)" or some such.


> > Surely even you can see problems with proposals you are putting 
> > forward, even if you don't think they are important enough to warrant 
> > discarding the idea.
> 
> Sometimes, but not always.

Wow, those must be some pretty damn good ideas. ;-)


> It would definitely be helpful (or it should be) to fallback on the 
> email list to assist with cons and drawbacks.

Indeed, I would encourage this. In fact that's the main reason for sending 
proposals to the list -- getting feedback.


> > Notice that it is *blatently obvious* (to me at least) that we should 
> > just keep using the <ol> element. Yet I still managed to come up with 
> > half a dozen other possible solutions, and listed pros and cons for 
> > each one.
> 
> Well, I'm curious how we proceed from here. If I put on my objective 
> hat, <ol> is no more "blatantly obvious" that it be included than 
> anything else (already included, proposed or waiting to be proposed). If 
> I look at the list of pros and cons, I still don't see "blatantly 
> obvious" either. There do seem to be multiple possible approaches one 
> might take. Incidentally my opinion and what I would advocate for would 
> be <ol>, but acting objectively I could definitely understand a 
> different approach.

Exactly. While for me one is obvious, you might see another one as 
obvious, or might see none as obvious. We all have different initial 
reactions. :-)

Where we go from there is that once everything is nicely described, Hyatt 
and I look at all the proposals, consider them, and update the spec in the 
way we think is, on the balance, the optimal choice for HTML and for the 
Web community at large. Hopefully in each case only a few people are 
disappointed. In some cases maybe we pick a poor choice and a lot of 
people say we're wrong (with expalanations why), and we change the spec in 
light of this.

In some cases, somebody might fundamentally disagree with a decision, and 
then we have the W3C Formal Objection process, which basically boils down 
to Tim Berners Lee making the final decision instead of Hyatt and myself.


> That is good to hear. Many members here have taken a very defensive 
> posture, often assuming that the HTML5 spec is done (e.g., what is 
> missing from the current draft is considered dropped from HTML5 as 
> opposed to not yet address as it may be in some cases).

Good lord, no, that's far from true.


> I've said this elsewhere, but I think its a mistake to publish the 
> differences with HTML4.01 document when it may just be certain aspects 
> have not been addressed.

Well, the spec won't be done for years, and we have to publish something. 
Anyway, that's a topic for Dan and Anne, I'll stay clear of the "what 
should we publish" issue. :-)


> > For example, the last time I looked at <table> markup in detail, my 
> > research suggested that scope="" handled the 80% case fine and thus we 
> > didn't need anything else (axis, headers, whatever). I look forward to 
> > studying this again in light of the thorough research that has been 
> > done since then.
> 
> I would think scope="" would handle much more than 80% of cases. 
> However, how could handling 80% or even more mean that we don't need 
> anything else (0ther than scope="")?

We can't handle everything (the 100% case). It's literally impossible, in 
that some people have conflicting needs ("simple language" and "covers 
this obscure edge case" being two conflicting needs). Personally I'm 
aiming for covering about 80% of the use cases of 100% of people. 
Accessibility concerns are therefore critical -- 100% of people includes 
people with disabilities -- but we don't need to handle all cases. For 
example, we don't have to handle 18-dimensional tables, as they aren't 
common at all.


> Again, with my objective hat on I have to conclude that different 
> members of the WG will come to different conclusions about what to 
> include in the language.

Naturally.


> Some may suggest that maybe only a 5% use case might warrant including 
> the facilities in the language Or 15%. Even if its as high as 20%, it 
> may currently get used by authors on only 1% of documents on the 
> internet and 3% of documents on intranets. It may be supported by 10% of 
> browsers, but 12% of all UAs (by implementation count). So its hard to 
> imagine what statistical research we might do that would provide 
> evidence of a need for certain facilities.

Don't take the 80% number too literally. It's an arbitrary number. I just 
mean "pretty common cases". If we can cover 90% of cases with features 
that are no more complex than those that can cover 80%, then we should 
shoot for 90%. If it turns out that we can cover 50% of cases trivially, 
but that the next 50% are all extremely complicated, maybe we stop at 50% 
until we have more experience in the field.


> Well the @summary example was just a hypothetical one in order to understand
> how this should  be handled generally. Again however I don't see how a
> non-scientific statistical analysis of some data a member collected will tell
> us anything about how to develop the HTML5 language. If we could actually
> perform scientific statistical analysis (with a budget to go along with it) we
> might be on to something.

Sure, better data is better. But even unscientific data is better than 
nothing at all.


> We know that accessibility features are seldom used. When they are used 
> they're often used incorrectly.

Indeed. This argues for having accessibility features be implicit rather 
than explicit. For example, the <progress> element has no explicit 
accessibility features, yet it is intrinsically accessible.


> Those who need them cannot consume content without them.

This isn't the case. In fact I'm pretty sure that most of the language 
features can be designed in a way that doesn't require explicit use of 
accessibility features without sacrificing accessibility.

The same, by the way, goes for usability.


> Would it make sense to simply post this to the email list and then add 
> it to the wiki?

Yes.


> The no-original-research rule seems very out-of-place here (though I can 
> definitely understand the desire to link to emails or threads of emails 
> discussing the issue).

Just post everything you post to the wiki to the mailing list at the same 
time, and you're safe. The concern is merely that we don't want people 
putting stuff on the wiki without having it in e-mail form as well.


> The statistics (again non-scientific statistics) might be useful trivia, 
> but I do not see how they provide useful information to make a decision 
> about the language features and the like.

Well for example these:

   http://code.google.com/webstats/2005-12/classes.html

...were a useful guide as to what elements we should add (<footer>, etc).


> Well, I'll stop with that. In summary, I think the email conversations 
> can and should be much more useful in preparing to write about the pros 
> and cons of an issue. However, I don't think that its necessarily the 
> case that we should have to begin on email before taking it to the wiki 
> (though I understand that's the rule you've laid out). I think we could 
> just as easily (or maybe even more easily) begin with a complete formal 
> wiki article and then discuss the wiki on the email list and add to the 
> article through the wiki process.

I encourage you to do it in whichever order you prefer (drafting an e-mail 
or drafting a wiki article), I would just request that you make sure you 
send everything to the list as well. It makes it a lot easier to track 
discussions.


Cheers,
-- 
Ian Hickson               U+1047E                )\._.,--....,'``.    fL
http://ln.hixie.ch/       U+263A                /,   _.. \   _\  ;`._ ,.
Things that are impossible just take longer.   `._.-(,_..'--(,_..'`-.;.'

Received on Thursday, 28 June 2007 03:40:13 UTC