- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Wed, 25 Aug 2010 11:18:15 +0200
- To: "public-vision-newstd@w3.org" <public-vision-newstd@w3.org>
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 I haven't read Harry's answers before writing these. 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
Received on Wednesday, 25 August 2010 09:18:28 UTC