W3C home > Mailing lists > Public > public-webplatform@w3.org > April 2013

Editor's Guide and flow infrastructure (was: Action Mode (was: Styling changes on tables and forms))

From: Doug May <intuedge@gmail.com>
Date: Thu, 4 Apr 2013 13:51:24 -0700
Message-ID: <CABPs60F23TuZ=4buzrbvJh1hACAAbYz6NfNzxhUP5Jvy+DiKHg@mail.gmail.com>
To: Doug Schepers <schepers@w3.org>
Cc: Lea Verou <lea@w3.org>, public-webplatform@w3.org, Scott Rowe <scottrowe@google.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#leahttp://lea.verou.me ✿ @leaverou
>>
>>
>>
>>
>>
>>
>>
>
>
>
Received on Thursday, 4 April 2013 20:51:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:13:45 UTC