W3C home > Mailing lists > Public > public-vision-newstd@w3.org > August 2010

Re: Answers on remaining questions

From: Ian Jacobs <ij@w3.org>
Date: Fri, 27 Aug 2010 21:22:58 -0500
To: Dominique Hazael-Massieux <dom@w3.org>
Message-Id: <B81220D1-2B72-4022-BB15-AB9BE42C0DD4@w3.org>
Cc: "public-vision-newstd@w3.org" <public-vision-newstd@w3.org>

On 25 Aug 2010, at 4:18 AM, Dominique Hazael-Massieux wrote:

> Hi,
>
> Per my action item ACTION-6, here are my views on the remaining open
> questions in the proposal document at
> http://www.w3.org/2010/07/community

Thank you, Dom. I have incorporated your suggestions (and moved things  
around a bit).

>
> I haven't read Harry's answers before writing these.

I haven't either. I will move on to his next. :)

  _ Ian


>
> Q: “Suggest small number of moderators; how are they chosen?  
> Staff?.. One
> proposal is a small number of staff, possibly assisted by publicly
> acknowledged volunteers.”
> As I suggested on IRC yesterday, I think this should start with an
> ad-hoc group of volunteers (some possibly some from the task force); I
> think we can come up with a more transparent and stable process for  
> this
> once we better understand the role and importance of these moderators.
>
> Q: “How are Community Supporters chosen?”
> I would suggest starting with a few volunteers in the W3C Staff; this
> role looks typically more sensitive (since it includes the power to
> close groups), and should probably be bound overtime to an election
> process of some kind.
> There should also be a well-defined appeal process for a community
> supporter decision.
>
> Q: “In Apache projects, there are various levels of responsibility  
> that
> you can have based on reputation. In an Apache progress, for instance,
> you get committer privileges. Are there analogous privileges for a
> Community Group (e.g., write access to the spec, or distinct mailing
> lists where one is world readable but only writable by select  
> people)?”
> Sounds a bit hard to answer generally, without knowing which tools  
> will
> be part of the default package for community groups.
> The “select” mailing list really hides the question of whom will be
> allowed to participate in a given group (and who gets to decide it);  
> but
> otherwise, I don’t think a selected-only mailing list should be  
> anywhere
> in our priority list of special roles.
> Restricting committer privilege to the reference version of the spec
> sounds more likely (esp. as decentralized versioning systems make it
> much easier for anyone to maintain separate branches of a given
> document).
>
> Q: “We need experienced editors. How do we bring new editors to the
> community?”
> As I alluded to yesterday, I think this is out-of-scope for this task
> force and that we shouldn't spend time on this question.
>
> Q: “Patent license requirements for Community Proposal Forum?”
> I think we need to keep the barrier for entry in that forum very low,
> which would suggest no requirement to me; but I’m not sure I can
> usefully give an opinion on this without a more detailed picture.
>
> Q: “Document distribution license requirements for Community Proposal
> Forum?”
> This would probably set on a tool by tool basis; e.g. none specific  
> for
> the archived mailing list or forum, one that allows others to
> edit/modify for the wiki; for the blog, maybe this should be left up  
> to
> the writer, maybe with a default to a CC of some sort.
>
> Q: “Software license requirements for Community Proposal Forum?”
> I think this should be left to whoever starts whatever software to
> decide.
>
> Q: “Discussion moderation for Community Proposal Forum?”
> I think this is referring to the Community moderators on which I’ve
> given an opinion above.
>
> Q: “Patent license requirements for Community Groups?”
> I don’t think this one can be answered independently of the transition
> to standards question; it would probably be more useful to start  
> listing
> the requirements for that question than trying to identify a direct
> answer immediately.
> Here are the requirements that I can think of:
> • individual based
> • relatively low-barrier
> • good-faith based
> • transparent
> • not linked to W3C Membership
> • not incompatible with transition to Rec-track process
>
> Some are probably still open:
> • uniform across community groups or not?
> • uniform across participants or not?
> • uniform over time or not? and if not, what are the specific  
> milestones
> that would matter?
> • linked or not to a well-defined scope? or on a document per document
> basis?
>
> Q: “Document distribution license requirements for Community Group?”
> OWFa in this list raises the question of whether the patent non-assert
> has any strong tie to the copyright license part of the agreement  
> (i.e.
> can we use one without the other)?
> In any case, I suggest an open license (CC or OWFa); I don’t know if
> that license would need special terms for W3C to facilitate the
> transition to Rec-track later on if needed.
>
> Q: “Software license requirements for Community Group?”
> I think this should be left to whoever starts whatever software to
> decide.
>
> Q: “Discussion moderation for Community Group?”
> Chairs aren’t currently required for community groups, but I expect  
> that
> when they exist in a group, they would naturally play that role; in
> their absence, I guess we would document a process where one  
> participant
> could contact the Community Supporters in case of disruptive  
> behaviors.
> (and I assume that Community Supporters would strongly suggest the
> designation of a Chair whenever that happens)
>
> Q: “Creation process for Community Groups”
> I don’t think we should require support from any W3C Member (esp. if
> this requires intervention from the AC Rep; I would probably care less
> if anyone with a Member account suffices).
> As was discussed on the call, a number of endorsement would probably
> suffice; but I think we should leave this fairly open when starting,  
> and
> refine this as we understand better the number of groups that would be
> asked to be created, the timing, the size of the community proposal
> forum, etc.; I think one requirement ought to be that a group can only
> be started if was presented to the community proposal forum first,
> though.
> For a starting point, a lightweight review from Community moderators
> and/or Community Supporters is probably going to suffice.
> In practical terms, I would keep the “create a group” interface
> available only to a limited number of people while we figure that
> process out.
>
> Q: “Who may participate in standardization process?”
> I think the invited experts process should already be ready to
> accommodate getting non-members to participate, provided the rule on  
> not
> allowing participants from ought-to-be Members is relaxed, but  
> combined
> with a proper RF-commitment from the employer.
> The problem is that this creates a loophole in the incentive to  
> become a
> W3C Member; maybe the time-based invitation would suffice in closing
> that hole? In any case, this needs a clear and transparent answer, so
> that contributors don’t feel trapped when they feel the time has  
> come to
> move to standardization.
>
> Q: “Should we reuse the name "Interest" or "Incubator" instead of
> "Community?" Or is the rebranding useful (and the processes will be
> sufficiently different that it is worth the new name)?”
> I prefer Community in the first place.
>
> Q: “Should there be a minimal level of support?”
> I think there can only be a group if you have at least 3 would-be
> participants :) Beyond that, I don’t think we should try to mandate
> anything at that time, but leave that part of the process pretty  
> open; I
> think we should actually not codify anything there unless that lacks  
> of
> codification creates suspicion that the process is biased and lacks
> transparency.
>
> Q: “Should we engage designers to develop a new visual brand for these
> new offerings?”
> I think the hiring question is probably out of scope of this task  
> force
> to answer, but it’s pretty clear to me that these new offerings would
> vastly benefit from a specific visual brand, both to make them
> attractive and to make it clear they are different from the existing  
> W3C
> Process.
> (The developers portal is another piece that could use lots of  
> designers
> love)
>
> Q: “For Community Proposal Forum and Community Groups, should
> participants have disclosure obligations over Rec track documents
> according to the W3C Patent Policy. This may affect whether some
> organizations allow their employees to participate in these  
> lightweight
> groups, even if disclosure is limited to personal knowledge.”
> What form would that obligation take? A commitment to do so when  
> joining
> the CPF or a Community Group?
> I’m not sure how that relates to the sentence that appears in any TR  
> doc
> under the patent policy (“An individual who has actual knowledge of a
> patent which the individual believes contains Essential Claim(s) must
> disclose the information in accordance with section 6 of the W3C  
> Patent
> Policy”).
> I would say a priori to leave the level of commitments for  
> participation
> in either the CPF or a Community Group as low as possible, and in
> particular as focused on the specifics of the group as possible, which
> would exclude the disclosure obligation, but maybe I’m not  
> understanding
> the proposition well-enough.
>
> Q: “Will Members ask that employee accounts be approved by Members?”
> It sounds like a question for the Membership rather than the task  
> force.
> But I think the real question is “will Members ask to gate the
> participation of their employees to the CPF? to Community Groups?”.
>
> Q: “Should we have some mechanism for granting write access to
> documents? This might be more stringent than the ability to post to a
> list.”
> I think that’s probably something that needs an answer on a tool by  
> tool
> basis; it’s probably simpler if we start on the basis that any
> participant can do anything in the considered Community Group, and let
> the social mechanisms manage the expectations. But it would probably  
> be
> useful to list more granular access controls as part of the longer  
> term
> requirements.
>
> Dom
>
>
>
>

--
Ian Jacobs (ij@w3.org)    http://www.w3.org/People/Jacobs/
Tel:                                      +1 718 260 9447
Received on Saturday, 28 August 2010 02:23:05 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 19:44:40 UTC