W3C home > Mailing lists > Public > public-web-bluetooth@w3.org > March 2015

Re: Writing a CG charter

From: Wayne Carr <wayne.carr@linux.intel.com>
Date: Sat, 28 Mar 2015 13:45:19 -0700
Message-ID: <551712DF.60402@linux.intel.com>
To: public-web-bluetooth@w3.org


On 2015-03-27 16:58, Jeffrey Yasskin wrote:
> Anssi, Wayne, and I have started to draft a charter for this community 
> group, in the 
> https://github.com/WebBluetoothCG/web-bluetooth/tree/charter branch. 
> You can see the current draft at 
> https://github.com/WebBluetoothCG/web-bluetooth/blob/charter/charter.md, 
> and the branch also contains changes to CONTRIBUTING.md and LICENSE*.
>
> I'd like to invite pull requests against that branch and discussion on 
> this thread.
>
> Once discussion dies down, I'll send a Call for Comments to this list 
> to adopt the charter, and I'll ask everyone who's committed to the 
> repository to explicitly agree to the new LICENSE file (the second is 
> probably unnecessary for people who've joined the CG, but it's 
> polite). When the charter is adopted, I'll merge it to the main 
> gh-pages branch.
>
> ----------------
>
> Some questions about the content of the charter:
>
> * Is the Scope what we want? I listed channel-based Bluetooth as 
> out-of-scope; should we also require a Charter change to add 
> Peripheral support? Since the Use Cases document is the main 
> definition of what's in scope, are there use cases we need to add 
> before finalizing the charter?
>
> * The CG charter template 
> (https://www.w3.org/community/council/wiki/Templates/CG_Charter) 
> suggests particular numbers of days for various votes and calls for 
> comments: 14 + 21 days to select a new chair (if I go mad with power); 
> 7-14 days to vote if we fail to achieve consensus; 30 days to amend 
> the charter. These numbers seem long to me. Can we shorten them? Are 
> they right as-is?

Those are mostly for instances where the group can't agree. Specifically --

For decisions, the CG can do it any way they like, including straw 
polls, or a 7 day Call for Consensus or whatever.  However they did it, 
the Chair decides what the consensus was.  If there is a disagreement 
about whether that was all done fairly, then it can go to a more formal 
vote.  So, it should be an exceptional circumstance when the group's 
friendly decision making has broken down.

The CG can decide how to change the Chair any way they want.  It's only 
if there are objections (5 people, no 2 from the same org), only then 
the formal election takes place.  So, if you want to resign, someone 
else volunteers and the group is happy, it's done. The formal thing 
isn't used.

So, for both of those, it's unusual and some bad problem - so time for 
everyone to get to vote is worth it -- it should never happen.

for amending the charter, for simple things like dates, it gets done 
just as a group decision.  The longer process is for changing the scope 
and things that may impact whether people want to still participate, 
things where legal departments may have to reavaluate participation.

>
> * The Contribution Mechanics section is pretty strict about what's 
> considered a contribution, to avoid general discussion on the mailing 
> list or a github issue being misconstrued as granting patent rights. 
> Is the wording there what we want?

Here is a suggestion to loosen it up (it's only important to know who 
did it if it is a Contribution to a spec).


    Contribution Mechanics

Community Group Participants agree that all Contributions will be 
documented in pull requests and commits for a particular document in the 
group's GitHub repository.

For Contributions to Specifications, if someone other than the 
Contributor makes the pull request, the pull request MUST indicate who 
the request was made on behalf of and MUST provide a link to the 
archived change request in a GitHub Issue or in the archived Community 
Group contrib or general mail list. This could be a link to archived 
meeeting minutes that clearly indicate who requested changes to a 
Specification. The information MUST be specific enough to easily 
determine who the Contributors were and that the intention was to change 
a particular Specification.

For software, the GitHub Contributing and License files describes how to 
Contribute and the license under which Contributions are made.




>
> Thanks,
> Jeffrey
Received on Saturday, 28 March 2015 20:45:50 UTC

This archive was generated by hypermail 2.3.1 : Saturday, 28 March 2015 20:45:51 UTC