I am of the opinion that the +1/-1 from non tc members can be valuable, but similarly it would be easy to get just comments. The TC is the body I expect to help determine the direction of cross project initiatives such as the logging guidelines. As a PTL I feel confident the TC is the right body to do the voting and the same rules as the governance repo (with chair +1 workflow) seems to be a great idea. Communicating the topics via the ML and the cross project meeting should help to get the PTLs and CPLs involved in the process, which is highly important. The ML can help to bring in other views.<div><br></div><div>I would rather trust the TC (who has not shown any reason to question their ability to determine community consensus) to help make sure we don't stall on these specs than have endless waiting. I like the proposal to use the TC voting rules. </div><div><br></div><div>--Morgan</div><div><div><div><br>On Wednesday, January 28, 2015, Thierry Carrez <<a href="mailto:thierry@openstack.org">thierry@openstack.org</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi everyone,<br>
<br>
When we first introduced the cross-project specs (specs for things that<br>
may potentially affect all OpenStack projects, or where more convergence<br>
is desirable), we defaulted to rather simple rules for approval:<br>
<br>
- discuss the spec in a cross-project meeting<br>
- let everyone +1/-1 and seek consensus<br>
- wait for the affected PTLs to vote<br>
- wait even more<br>
- tally the votes (and agree a consensus is reached) during a TC meeting<br>
- give +2/Worflow+1 to all TC members to let them push the Go button<br>
<br>
However, the recent approval of the Log guidelines<br>
(<a href="https://review.openstack.org/#/c/132552/" target="_blank">https://review.openstack.org/#/c/132552/</a>) revealed that those may not<br>
be the rules we are looking for.<br>
<br>
Sean suggested that only the TC chair should be able to workflow+1 to<br>
avoid accidental approval.<br>
<br>
Doug suggested that we should use the TC voting rules (7 YES, or at<br>
least 5 YES and more YES than NO) on those.<br>
<br>
In yesterday's meeting, Sean suggested that TC members should still have<br>
a -2-like veto (if there is no TC consensus on the fact that community<br>
consensus is reached, there probably is no real consensus).<br>
<br>
There was little time to discuss this more in yesterday's TC meeting, so<br>
I took the action to push that discussion to the ML.<br>
<br>
So what is it we actually want for that repository ? In a world where<br>
Gerrit can do anything, what would you like to have ?<br>
<br>
Personally, I want our technical community in general, and our PTLs/CPLs<br>
in particular, to be able to record their opinion on the proposed<br>
cross-project spec. Then, if consensus is reached, the spec should be<br>
approved.<br>
<br>
This /could/ be implemented in Gerrit by giving +1/-1 to everyone to<br>
express technical opinion and +2/-2 to TC members to evaluate consensus<br>
(with Workflow+1 to the TC chair to mark when all votes are collected<br>
and consensus is indeed reached).<br>
<br>
Other personal opinions on how you'd like this repository reviews to be<br>
run ?<br>
<br>
--<br>
Thierry Carrez (ttx)<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</blockquote></div></div></div>