RE: CSS or bust???


This looks wonderful. The only change I would suggest to the language here is:

6) The next Wednesday, we take stock on what actually happened, how much got done and what wasn't done, and we pick the next set of articles.

--> 6) Prior to the next Wednesday, we take stock on what actually happened, how much got done and what wasn't done, and we pick the next set of articles. We report findings on the next Wednesday.

Let the WPD Wednesday be about writing. Let the organizers be about organizing.

-----Original Message-----
From: Doug Schepers [] 
Sent: Friday, May 3, 2013 12:36 AM
Subject: Re: CSS or bust???

Hi, Eliot-

As Julee and Scott mentioned, this was the central subject of our Recruitment call. In my mind, it makes little sense to spend energy on recruitment if we don't have a clear contribution rhythm in place to convert interested potential contributors into active contributors. So, I'd like us to break things down into even clearer goals.

Eric Shepard (Mozilla) has a good methodology for MDN called "Wiki Wednesday"  (Janet, please correct me on details): he picks several topics or articles that need work, and makes a call for volunteers (on email and Twitter) for people to cover those articles.

I'd like to adopt this methodology. We have 159 CSS pages with status "unknown" (probably not started) and another 8 that "need work"; that's
167 pages. We want to be in good shape in roughly 10 weeks (more or less). So, that's 17 pages a week. Each of these articles may take 2-5 hours to complete; so that's an average of 60 solid hours per week of work that we are looking for. Do we have enough contributors for that? 
It's not yet clear, but I'm optimistic.

Here's what I propose:

1) We pick a day ("WPD Wednesday"?), and pick 17 CSS property articles for that week (it might be nice to sort them into topic clusters, but I don't want to create makework)

2) To prevent people from being intimidated by a blank page, we create stubs for those 17 articles, with the link to the specification where you will find the basic information to start from; I would hope we could automate this with a script (it would be nice to also insert the topic

3) We put the word out for contributors, on this list, on the blog, on Twitter, on the CSS public mailing list, among our companies, in the site notice, etc.; we direct them to this email list, or IRC or Twitter if they are not into email

4) When people show up to commit, we have designated "greeters" for each page (one of the core community folks who knows how to do things will each take 3-5 pages to be responsible for), who trains and encourages the contributor, removing roadblocks and facilitating quality contributions

4a) If we get more contributors than we need, we pull a few more articles into the list

4b) If we don't get enough contributors, we either ask the existing contributors to take on a little more work, or we make a new call, or we adjust our goals (date or amount)

5) Once a contributor has finished their task, they tell their greeter, who make sure the next stage happens (typically, review), and they take care of the "paperwork" in the Giant Scary Spreadsheet

5a) We ask the contributor to tweet about their contribution, to give themselves props and to spread the word; we retweet these from @webplatform

6) The next Wednesday, we take stock on what actually happened, how much got done and what wasn't done, and we pick the next set of articles

6a) We blog about the progress, and about the next set of work. (Rinse, repeat; apply praise liberally.)

I'd also like to split it down into more discrete, manageable tasks (as 
I alluded to):

a) basic facts, such as overview table, syntax, and values

b) explanatory text, such as the introduction (summary), usage, and notes

c) examples, with explanations

d) review, and flagging and unflagging

e) links to tutorials and other materials (either inside WPD or on the 
wider web)

Each contributor might sign up for one or more tasks for one or more 
articles; you only want to fill in basic facts? Great, take 3 or 4 
articles, that will probably go quick. You are good at a more creative, 
time-consuming skill like explanatory text? Ok, maybe you should only 
commit to 1 or 2 pages. You like making examples? Pick 2 or 3 articles. 
You want to do the complete page? Okay, pick 1 and go to town.

(Note that I don't include compatibility table information in this 
breakdown; we will soon have automated compatibility tables, so we 
should discourage people from trying to edit this manually for now.)

In doing this, we should send a clear initial and continuous signal: 
this is a push to get to beta, and this is the deadline. This is not the 
sustained pace we will have going forward; we're asking people to make a 
concerted short-term sacrifice to help us all reach a concrete goal.

I've been speaking to Julee about this quite a bit on IRC, and I imagine 
that we'll come up with refinements of this; she's already written up 
some great notes [1]. I welcome suggestions and feedback on details.

All this said, it also bears saying that volunteer resources are not 
necessarily fungible; people will work on what they are interested in. 
Max Polk has jumped on the MSDN-JS project, and has a methodology, and 
we would be silly to ask him to stop that and work on CSS instead. So, 
some parallel work is healthy and reasonable.

There is nothing hard about this. This would require very little 
up-front work, except possibly the optional populating script and the 
optional topic-clusters (which I think would take 2-3 hours of sitting 
down and sorting), and deciding who will be the "greeters" (or 
"ambassadors"). We could start this next week.

Maybe I'm naive, but I actually think that with this systematic and 
streamlined approach, and with the awesome community waiting in the 
wings for guidance, we will be surprised by how great the response will be.

Can I get an amen?



On 4/30/13 3:37 PM, Eliot Graff wrote:
> Hi All.
> [[Before I ask these questions, I want to say that I am as guilty of
> contributing to this as anyone, having recently introduced the 400+
> JavaScript pages in to the mix.]]
> Are we really placing our energies in the right places? Are we
> working on the right things? Or are we losing focus?
> I thoroughly understand that there are a _many_ important and
> wonderful aspects of WPD that we could be creating, enhancing, and
> building, but I think we may be drifting from our original decisions
> (and if not, this will serve as a verification of our course of
> action). I was under the impression that we determined that we would
> identify and work on one section of WPD at a time to get that area up
> to what we considered "beta content", and that we were going to do
> that starting with the CSS properties. We're not anywhere near
> complete on those, are we? If we are, I apologize, and carry on. But
> I look at the CSS Properties spreadsheet [1] and I see a ton of work
> left to go. Yet, over the past couple of weeks, we are all (myself
> included) very eager to start work on JavaScript reference,
> Beginner's Guide, DOM, and other large projects (I'm sorry to pick on
> these in particular).
> My call to this community is this: We should validate that our
> priorities are sound (from time to time) and strive to stay focused
> on our highest priority items prior to embarking on new work. In
> short, we need to hold ourselves accountable to our goals. Certainly,
> this is true while our community is still small but growing. Maybe
> later, when we're a robust and enormous group, we can have the luxury
> of being less strident.
> Can we reiterate (in mail or during upcoming telcons) what our
> priorities are currently, and make sure that we're staffed to
> accomplish them in a timely manner?
> I welcome discussion about this. My main goal is to help us get to
> beta as soon as possible under our chosen criteria.
> Most sincerely,
> Eliot
> [1]


Received on Friday, 3 May 2013 15:25:44 UTC