Open Stack

Sorry I'm late to the party.

I won't disagree that we have room to grow here; in fact, I'd love to see
our review throughput increase, both in terms of the number of reviews
we're able to perform and the number of people performing them across the
board.  I also won't disagree that there have been times where review
turnaround has been slower than others; however, I'd also like to point out
that the response to reviews (whether it's further discussion or addressing
review feedback) has also been slower at times than others.

I'm not arguing that either one of those is more frustrating than the
other, but in my mind it's an exercise in building trust.  I'm always happy
to review changes that come in that I feel qualified in reviewing, and I'm
not above saying "today's a bit busier than usual, so it may be later
before I can take a gander" -- we all have day jobs that demand our
attention, even if those work periods don't line up across time zones.  I
don't think it's unreasonable to ask individuals desiring a quicker
turnaround time on reviews for a quicker turnaround time on the feedback
provided, else we don't really move forward here.

I don't think solving the perceived priority and review latency issues is
an insurmountable problem.  The first step to tackling this is continued
involvement in the channels mentioned above.  Our weekly meeting attendance
has fluctuated in the past, and I'm sure we can attribute some of that to
the time zone difference; however, it's been pretty sparse recently.  While
our mailing list involvement may not be the best (it's easy to lose track
of emails, personally), we've always had a standing portion of our weekly
meeting devoted to posting changes we'd like reviewed.  One of the items
brought up recently was ensuring the following meeting's etherpad is posted
at the end of the current weekly meeting so we've got ample time to get
visibility on those.  Furthermore, our weekly meetings are where we tend to
discuss what's happening with OpenStack-Helm at any given time.  Whether
it's expanding what our jobs do, talking about what's required for getting
new features in, or determining what someone can work on to add value, our
weekly meeting would be the place to attend (or at least check out the
meeting log if you can't make it).  Our IRC channel is another -- I see
plenty of chatter happening most days, so others needn't be shy about
specifically calling out for reviews in the channel.  I'm certain there are
individuals who can't or don't want to be in IRC for reasons of their
choosing, and that's fine - I personally plan to be more involved with the
mailing list, but I also can't and don't want to be answering emails all
day either.  Once again, it's give and take.

I'd challenge everyone in this thread to be part of the solution.  We want
to bring others in and accommodate their needs and uses, we want to grow a
more diverse core team, and I personally enjoy talking to strangers on the
internet.  However, that requires active, continuous involvement from all
parties involved, not just the core reviewer team - we're not the only ones
who are capable of reviewing changes.

I'm sure there's a path forward here, so let's find it together.

Steve

On Thu, Feb 21, 2019 at 12:28 PM Jean-Philippe Evrard <
jean-philippe at evrard.me> wrote:

> Hello,
>
> These were just examples. We can always find give counter examples of
> reviews lagging behind by checking in gerrit.
>
> As far as I understand it, the problem is not that people don't get
> reviews in a timely fashion, is how they are prioritized.
> In Openstack, reviews stays behind for a certain time. It's sad but normal.
>
> But when people are actively pointing to a review, don't get a review, and
> others patches seem to go through the system... Then a tension appears.
> That tension is caused by different understanding of priorities. I raised
> that in the past.
>
> I think this is a problem we should address -- We don't want to alienate
> community members. We want to bring them in, by listening to their use case
> and work all together. For this project to become a community project, we
> truly need to scale that common sense of priorities all together, far
> beyond the walls of a single company. We also need to help others achieve
> their goals, as long as they are truly beneficial for the project in the
> long term. I like this guidance of the TC:
> https://governance.openstack.org/tc/reference/principles.html#openstack-first-project-team-second-company-third
> . Let's get there together. Long story short, I would love to see more
> attention to non AT&T patches. I guess IRC, ML, or meetings are good
> channels to raise those. Would that be a correct assumption for the future?
>
> Anyway, I am glad you've answered on this email.
>
> Please keep in mind it's not possible for everyone to join IRC, some
> people are not fluent in English,  and some people simply don't want to
> join instant messaging. For those, the official communication channel is
> also the emails, so we should, IMO, treat it as an important channel too.
>
> Regards,
> Jean-Philippe Evrard (evrardjp)
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190221/f9e45cdb/attachment-0001.html>