<div dir="ltr">Sorry I'm late to the party.<div><br></div><div>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.  </div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>I'm sure there's a path forward here, so let's find it together.</div><div><br></div><div>Steve</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 21, 2019 at 12:28 PM Jean-Philippe Evrard <<a href="mailto:jean-philippe@evrard.me">jean-philippe@evrard.me</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hello,<br>
<br>
These were just examples. We can always find give counter examples of reviews lagging behind by checking in gerrit.<br>
<br>
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.<br>
In Openstack, reviews stays behind for a certain time. It's sad but normal.<br>
<br>
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.<br>
<br>
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: <a href="https://governance.openstack.org/tc/reference/principles.html#openstack-first-project-team-second-company-third" rel="noreferrer" target="_blank">https://governance.openstack.org/tc/reference/principles.html#openstack-first-project-team-second-company-third</a> . 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?<br>
<br>
Anyway, I am glad you've answered on this email.<br>
<br>
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.<br>
<br>
Regards,<br>
Jean-Philippe Evrard (evrardjp)<br>
<br>
</blockquote></div>