Yea, this was what I mean by my question "What is the action when an SLO is
missed?"

For example, the way we implement could just be a line in the contribution
guide like this:

"We aspire to respond quickly to all pull requests, even if it can take
some time to review them. If you have not heard a response in <duration>
then please @mention someone again, try someone else, or reach out on Slack
or dev@."

It does sound a bit overly technical to say we have an SLO of <duration>
with an SLA that you should ask again.

Kenn

On Thu, Jun 7, 2018 at 7:16 AM Jean-Baptiste Onofré <[email protected]> wrote:

> Agree.
>
> Having a best effort is fine but not a strong commitment, because, like
> in any Apache project, lot of people works on the project in their spare
> time, or even during business time,  with lower priority.
>
> Regards
> JB
>
> On 07/06/2018 16:11, Thomas Weise wrote:
> > I like the idea of speeding up code review and promptly responding to
> > PRs, since this is more motivating to the contributors, especially those
> > that are not committers.
> >
> > However, the notion of SLO or target response time is something that
> > works within a company with dedicated resources. It may not be the right
> > approach for a diverse community with contributors of various
> > backgrounds and time commitments. Establishing such policy as
> > expectation at the project level seems problematic.
> >
> > Perhaps this can be a guideline or recommendation, but I don't see how
> > it can be measured or enforced at the project level.
> >
> > Thanks,
> > Thomas
> >
> >
> > On Thu, Jun 7, 2018 at 6:09 AM, Etienne Chauchot <[email protected]
> > <mailto:[email protected]>> wrote:
> >
> >     Yes, I agree with that, I thought it was the delay to start the
> review.
> >     +1 then on the delay to answer
> >
> >     Etienne
> >
> >     Le jeudi 07 juin 2018 à 11:02 +0100, Reuven Lax a écrit :
> >>     However I think it's reasonable to expect a response within 3
> >>     days, even if that response is not an actual review. For instance,
> >>     the response could be "I'm extremely busy right now, and it will
> >>     take another week for me to get to this."
> >>
> >>     On Thu, Jun 7, 2018, 10:40 AM Etienne Chauchot
> >>     <[email protected] <mailto:[email protected]>> wrote:
> >>>     +1 on the purpose, but I think 3 business days for proposal 1 are
> >>>     over-optimistic.
> >>>     As an example I saw PRs taking weeks before the review started.
> >>>     IMHO, I think you should consider raising up the 3 days bar a bit.
> >>>
> >>>     Best
> >>>     Etienne
> >>>
> >>>     Le mardi 05 juin 2018 à 15:04 -0700, Andrew Pilloud a écrit :
> >>>>     The one thing that seems a little odd to me is using business
> >>>>     days. The beam community spans across company and country
> >>>>     boundaries, which makes business days a slightly ambiguous
> >>>>     concept. Not everyone's holidays and weekends line up. I also
> >>>>     agree with Alan, we need to build in time to disconnect. If this
> >>>>     is opt-in, it might make sense to collect working hours and make
> >>>>     it easy to opt out if you aren't going to be available for an
> >>>>     extended period. Until recently we had a page listing committer
> >>>>     companies and time zones. Bringing that back would be a good
> option.
> >>>>
> >>>>     Andrew
> >>>>
> >>>>     On Tue, Jun 5, 2018 at 2:29 PM Huygaa Batsaikhan
> >>>>     <[email protected] <mailto:[email protected]>> wrote:
> >>>>>     Thanks Ken for pointing out that vote is a two step process. I
> >>>>>     will write an extended written doc about pros and cons of the
> >>>>>     SLO and any related topics. In the meantime, feel free to use
> >>>>>     this thread to express any suggestions and concerns.
> >>>>>
> >>>>>     Thanks, Huygaa
> >
> >
>
> --
> Jean-Baptiste Onofré
> [email protected]
> http://blog.nanthrax.net
> Talend - http://www.talend.com
>

Reply via email to