Re: Writing a CG charter

On Sat, Mar 28, 2015 at 1:45 PM, Wayne Carr <wayne.carr@linux.intel.com>
wrote:

>
>
> 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.
>
> Works for me.

>
>  * 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.
>

That looks good to me. Would you send a PR changing the charter to use that?

Jeffrey