A pull request to the website makes sense to me as that is where the policy
change to RTC will be communicated to new contributors.  If anyone has
objections to the change, they can -1 the pull request.

On Tue, Aug 8, 2017 at 2:48 PM Christopher <ctubb...@apache.org> wrote:

> (by "update the website", I mean, just do a PR against the website for
> formal review)
>
> On Tue, Aug 8, 2017 at 2:36 PM Christopher <ctubb...@apache.org> wrote:
>
> > Do we even need to vote? I think we already have consensus. Can probably
> > just update the website at this point.
> >
> > On Tue, Aug 8, 2017 at 2:01 PM Keith Turner <ke...@deenlo.com> wrote:
> >
> >> Any thoughts about the following vote email?
> >>
> >> Subject : [VOTE] Allow bypassing RTC for urgent changes
> >>
> >> All changes to Fluo are currently made via review then commit (RTC).
> >> Please
> >> vote on allowing bypassing RTC for urgent updates with the following
> >> commit
> >> process.
> >>
> >>  * Make an appropriate level of effort to request a review.
> >>  * If applicable,  take appropriate steps to ensure that their actions
> >> can be
> >>    reversed.
> >>  * Send an explanation to the dev list (or private list, if sensitive)
> >>    immediately after committing justifying the urgency.
> >>
> >> Such emergencies should be extremely rare, and would typically only
> apply
> >> to
> >> things not blocked by a release vote (such as a website change).
> >>
> >> This vote is open for 3 days.
> >>
> >> On Thu, Jul 27, 2017 at 3:04 PM, Christopher <ctubb...@apache.org>
> wrote:
> >> > How about something like:
> >> >
> >> > """
> >> > Reviews may only be bypassed in the case of an emergency, and only
> >> after an
> >> > appropriate level of effort has been made to request a review. Before
> >> > bypassing a review, the committer should take appropriate steps to
> >> ensure
> >> > that their actions can be reversed, if necessary. The committer should
> >> also
> >> > send an explanation to the dev list (or private list, if sensitive)
> >> > immediately afterwards justifying the urgency. The PMC members will
> >> decide
> >> > whether the action was warranted, and what follow-on actions should be
> >> > taken, if any. Such emergencies should be extremely rare, and would
> >> > typically only apply to things not blocked by a release vote (such as
> a
> >> > website change).
> >> > """
> >> >
> >> > The above proposed wording has the benefit of being simple, flexible,
> >> and
> >> > accountable, but not being tied to any complex rules like tagging,
> >> > labeling, waiting for specific durations, etc. that can undermine the
> >> > efficacy of an emergency action. It's also very broad, so it isn't
> >> > dependent on specific workflows or infrastructure tools, which can
> >> change
> >> > over time.
> >> >
> >> > On Thu, Jul 27, 2017 at 11:12 AM Keith Turner <ke...@deenlo.com>
> wrote:
> >> >
> >> >> In addition to tagging as urgent, a short explanation of why its
> >> >> urgent should be given.
> >> >>
> >> >> On Thu, Jul 27, 2017 at 11:10 AM, Keith Turner <ke...@deenlo.com>
> >> wrote:
> >> >> > I have been thinking that it may be useful to relax RTC for urgent
> >> >> > website updates.   I can not imagine this being needed for Fluo or
> >> >> > Fluo Recipes because of the 3 day release process.  However, the
> >> >> > website is always immediately available after any update.  It would
> >> be
> >> >> > nice to have an agreed on mechanism for bypassing RTC for the
> >> website.
> >> >> > Possibly something like the following :
> >> >> >
> >> >> >  * Create PR for website and tag it urgent
> >> >> >  * Attempt to contact other PMC members
> >> >> >  * Wait X time (for example 10 mins)
> >> >> >  * After X time if no one has indicated they are reviewing, then
> >> >> > commiter can push
> >> >> >
> >> >> > I think the policy should include something like : should this
> policy
> >> >> > ever cause strife in the community, it must be repealed
> immediately.
> >> >>
> >>
> >
>

Reply via email to