Feedback on Process-20140801 section 5

I'm sorry that I didn't send this feedback on [1] earlier, I've been busy. 

{Section 5 Activities}

> This section describes the mechanisms for establishing consensus within the areas of Web development the Consortium chooses to pursue.

This is the first instance of <the Consortium> to mean the W3C. The abstract used <The mission of the World Wide Web Consortium (W3C)>, the Introduction used <Consortium-wide>.
I'd suggest using W3C.


> W3C starts an Activity based on interest from the Members and Team.

There are RFC words in this section, s/starts/should start/

> W3C Members build interest around new work through discussions among Advisory Committee representatives, Chairs, and Team, and through the Submission process.

s/build/should build/

> The Team tracks Web developments inside and outside W3C, manages liaisons, and organizes Workshops.

s/tracks/[must|should] track/ -- must is too strong for <outside> but applies to the others, then please split into distinct must and should statements.

> Based on input from the Team and Members about the structure and scope of an Activity, the Team sends an Activity Proposal to the Advisory Committee.

s/sends/should send/

> This is a proposal to dedicate Team and Member resources to a particular area of Web technology or policy, and when there is consensus about the motivation, scope, and structure of the proposed work, W3C starts a new Activity.

This is too long of a sentence. s/, and when/. When/
If the previous s/starts/should start/ didn't apply then, it should here.


> Each Activity has its own structure that generally includes Working Groups, Interest Groups, and Coordination Groups.

s/has/should have/ ?

> Within the framework of an Activity, these groups produce technical reports, review the work of other groups, and develop sample code or test suites.

s/or/and/ ?


> The progress of each Activity is documented in an Activity Statement.

<is> -> rfc should/must?

> Activity Statements describe the goals of the Activity, completed and unfinished deliverables, changing perspectives based on experience, and future plans.

<describe> -> rfc

> At least before each Advisory Committee meeting, the Team SHOULD revise the Activity Statement for each Activity that has not been closed.

<At least before> is awkward. s/At least before/before/
Feel free to add <Team MAY revise the Activity Statement for an Activity at any other time.> If there are exceptions, they should be noted here.

> Refer to the list of W3C Activities [PUB9].

TEAM: PUB9 [2] does NOT list Activities at all. Which is really a non-sequitor.

-> Note: This list MAY include some Activities that began prior to the formalization in 1997 of the Activity creation process.

Since we're appparently updating the Process document, perhaps we should change MAY to MUST as:

-> Note: This list MUST include Activities that began prior to the formalization in 1997 of the Activity creation process until they are all closed (which MAY never happen).

> The Team MUST notify the Advisory Committee when a proposal for a new or modified Activity is in development.
> This is intended to raise awareness, even if no formal proposal is yet available. 

the <is> here is odd - it isn't rfc language.


> After a Call for Review from the Director, the Advisory Committee reviews and comments on the proposal.

s/reviews and comments/shall review and comment/


> The Director announces to the Advisory Committee whether there is consensus within W3C to create or modify the Activity (possibly with changes suggested during the review).

s/anounces/shall announce/

This statement should indicate a timeframe relative to the expiration of the timewindow for the review period, as in <which must be after the review period expires> or <which must be within X time units of the expiration of the review period>

> For a new Activity, this announcement officially creates the Activity.

I'm not a fan of <officially creates>, perhaps s/creates/starts/

> Note: There is no appeal of a decision not to create an Activity; in general, drafting a new Activity Proposal will be simpler than following the appeal process.

I'd rather <An AC rep should draft a new Activity Proposal if they want an Activity to be created and it wasn't (as this is simpler than the appeal process)>.


> Context information. Why is this Activity being proposed now?
> What is the situation in the world (e.g., with respect to the Web community, market, research, or society)? within the scope of the proposal?

There's an embedded <?> in the middle of this sentence.

> Is the community mature/growing/developing a niche?

<mature> doesn't agree with <growing> and <developing> (<maturing> would)
Is <a niche> distinct from <mature...developing>?

> A description of the Activity's scope.
> How might a potential Recommendation interact and overlap with existing international standards and Recommendations?

What about other Activities/WGs within W3C?

> What organizations are likely to be affected by potential overlap (see the section on liaisons with other organizations)?
> What should be changed if the Activity is approved?


> The duration of the Activity.
...
> The expected timeline of the Activity, including proposed deliverable dates and scheduled Workshops and Symposia.

It feels odd to me that duration and timeline are separated by another line item.

> What groups will be created as part of this Activity and how those groups will be coordinated. For each group, the proposal MUST include a provisional charter. Groups MAY be scheduled to run concurrently or sequentially (either because of a dependency or an expected overlap in membership and the desirability of working on one subject at a time). These charters MAY be amended based on review comments before the Director issues a Call for Participation.
...
> If known, the date of the first face-to-face meeting of each proposed group. The date of the first face-to-face meeting of a proposed group MUST NOT be sooner than eight weeks after the date of the Activity Proposal.

It feels odd to me that the two WG items are separated by another line item.

> Information about known dependencies within W3C or outside of W3C.

s/within/both within/; s/or/and/‎


[1] http://www.w3.org/2014/Process-20140801
[2] http://www.w3.org/Consortium/activities‎

Received on Wednesday, 13 August 2014 01:27:47 UTC