Excerpts from Thierry Carrez's message of 2015-06-19 10:01:46 +0200: > Tony Breeds wrote: > > The first thing is using the review to "vote" on meeting times. > > - I'm not certain this is the best workflow but it's something worth palying > > with. The key is identifying that a review is a suggestion and then > > identifying when that suggestion becomes golden are the key things. So > > perhaps if you're looking for votes on a review -W it? Or add a comment > > like: > > This a a vote if there are no -1's after $datetime please merge then? > > I think the irc-meetings review should not be used to decide on a > meeting time. Same way you don't post multiple implementations of a > feature and "vote" for the best one. You shouldn't propose something you > don't have the intention to see merged, otherwise it's a waste of > reviewers time.
Yes, doodles are much better for that. > > Knowning that a meeting change is *correct* / endorsed. > > - When a Change comes in I do verify that the new time seems to match the > > project wiki / documentation I can easily find. However it's possible, > > as an outsider to your project, I may miss sometime and approve a "bad" > > change. It isn't great for the calendar to list the wrong meetiung > > information. I have 2 suggestions: > > 1) I "require" the PTL to +1 the meeting change ; or > > 2) The commit message contains a like to some public log that indicates > > the > > change has been discussed. (say an IRC log or mailing list archive) > > These 2 options aren't exclusive. We could of course just accept mistakes > > will be made and handle reverts quickly but I don't really like that. > > I think it's fair to request that the meeting is proposed by the group > lead, *or* that the commit message points to reference information that > shows that the team lead is fine with it, *or* has the lead +1 on it. As a reviewer, I would prefer that the lead submit the patch or +1 it to avoid any ambiguity with my interpretation of meeting logs. Doug __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
