Open Stack

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.

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

-- 
Thierry Carrez (ttx)

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150619/ae306245/attachment.pgp>