- From: Doug May <intuedge@gmail.com>
- Date: Thu, 4 Apr 2013 13:51:24 -0700
- To: Doug Schepers <schepers@w3.org>
- Cc: Lea Verou <lea@w3.org>, public-webplatform@w3.org, Scott Rowe <scottrowe@google.com>
- Message-ID: <CABPs60F23TuZ=4buzrbvJh1hACAAbYz6NfNzxhUP5Jvy+DiKHg@mail.gmail.com>
>From this thread and the latest sprint, I am starting to reverse-engineer more of the community's editor guidelines. Here are some straw content fragments (read it as raw doc sprint feedback, or wait for the feedback summary and skip these details). I'll churn some of it into wiki content soon. "Seek feedback early and often" - ask on the list, or on the IRC (probably needs examples of a number of cases) - this is a great context for why/how to flag your page after you have worked on it (cases and examples would be good) - also points to a (set of) queue(s) where I can post changes for rapid (or less so) feedback (ultimately, where m,n people must,can pull each item, based on the case) - probably need pages on how to read the page change history, and on the validation criteria (and how to provide feedback) by case We have multiple domains of change, with distinct community change flows. - content = jump right in (start with checkout and instructions if needed), and then have it looked at (after both creation and editing) - templates = special team (for now, do not touch) - styling = publish a sample with rationale (design goals), then notify the list with a summary and a link, and engage with feedback (maybe cases for tweaks vs. extensions vs. rework); also need how to suggest or request such changes - projects, tasks, bugs = pending, but we should start looking at cases and gathering working proposal fragments on the wiki - process = still figuring this one out; current best guess is that this has a list of cases; maybe start with commenting on an existing page, or creating a personal page for the discussion, and notify the list with a summary and a link, and engage with feedback (hint -- do not just edit any existing process, just because it is published as wiki content) - wiki/team how-to = partly like content and partly like process - mission, vision, beta requirements = treat as legacy and substantially fixed, but ok to ask about and discuss Several of the above point to the need for some basic guidelines and encouragement for how to set up personal pages for stuff that has not been adequately engaged with by the community (we have some notes on this around Scott's recent modeling). Perhaps in the community building efforts we could also look at volunteer identity-social-specialties pages, and contribution credit and highlighting, as part of the larger picture (so when you show up a second time, or make a second contribution outside your first event, you are invited or encouraged to set up a more complete identity). I also have Scott and Doug's guidelines on single-topic email threads. Something like an org chart (who to go to try out an idea) would be nice. There is a strong prejudice towards doing everything on the public list, but not everything gets done on the public list, so some sensible cases and examples will help. DougM On Thu, Apr 4, 2013 at 12:11 PM, Doug Schepers <schepers@w3.org> wrote: > Hi, folks- > > One of the community was a bit surprised by these changes, and I realize > that we should have socialized them better. I was the one who gave Lea the > go-ahead to push the changes to the production site, so I bear > responsibility for poor coordination. > > I'd like to turn this into a consensus opportunity for future actions. > > My instinct (which is not always accurate) was that we should handle > designs much like we handle content: encourage action, seek feedback early > and often, and iterate towards consensus. > > In this case, I feel I failed in the "seek feedback early and often" > stage. A better approach, which Lea suggested a couple minutes ago, would > have been for her to simply publish the changes on the test wiki, and for > us to show them to the community first before committing them to the main > wiki; in the future, we'll try to do that instead, since a change like this > affects everyone (and even if they like the change, they may want to have a > say in it first, and might not like to be surprised). > > I do want to emphasize the first premise, "encourage action", especially > in a disparate group like this where indecision can lead to inaction. So, > in spite of this slip-up, I still encourage everyone to take initiative on > actions, and learn from my mistake by suggesting large changes first, then > looping around for quick feedback. > > Regards- > -Doug > > On 4/4/13 2:55 PM, Lea Verou wrote: > >> Hi everyone, >> >> After checking with Doug, I took the initiative of styling the >> wikitables to be the same as the browser compat tables, and styled the >> forms too, so that the edit page looks a bit nicer. >> One issue is that tables without the .wikitable class are currently >> unstyled, which will be solved. >> If you notice any other issues or have feedback, we’re open to changes :) >> >> Cheers, >> Lea >> >> Lea Verou >> W3C developer relations >> http://w3.org/people/all#lea ✿http://lea.verou.me ✿ @leaverou >> >> >> >> >> >> >> > > >
Received on Thursday, 4 April 2013 20:51:56 UTC