<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jul 15, 2016 at 1:09 AM, Jeff Darcy <span dir="ltr"><<a href="mailto:jdarcy@redhat.com" target="_blank">jdarcy@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">> The feedback I got is, "it is not motivating to review patches that are<br>
> already merged by maintainer."<br>
<br>
</span>I can totally understand that. I've been pretty active reviewing lately,<br>
and it's an *awful* demotivating grind. On the other hand, it's also<br>
pretty demotivating to see one's own hard work "rot" as the lack of<br>
reviews forces rebase after rebase. Haven't we all seen that? I'm<br>
sure the magnitude of that effect varies across teams and across parts<br>
of the code, but I'm equally sure that it affects all of us to some<br>
degree.<br>
<span class=""><br>
<br>
> Do you suggest they should change that<br>
> behaviour in that case?<br>
<br>
</span>Maybe. The fact is that all of our maintainers have plenty of other<br>
responsibilities, and not all of them prioritize the same way. I know I<br>
wouldn't be reviewing so many patches myself otherwise. If reviews are<br>
being missed under the current rules, maybe we do need new rules.<br>
<span class=""><br>
> let us give equal recognition for:<br>
> patches sent<br>
> patches reviewed - this one is missing.<br>
> helping users on gluster-users<br>
> helping users on #gluster/#gluster-dev<br>
><br>
> Feel free to add anything more I might have missed out. May be new<br>
> ideas/design/big-refactor?<br>
<br>
</span>Also doc, infrastructure work, blog/meetup/conference outreach, etc.<br></blockquote><div><br></div><div style="">Bug triage (more generally collecting information from field on how things are working, what we are lacking)</div><div style="">Testing</div><div style="">Performance measurements</div><div style="">Futuristic thinking (new features, rewrites etc)</div><div style="">Channelizing our collective brain-power and prioritization of things to work on (roadmap etc)</div><div style="">Handling competition (Defence/Constructive arguments etc).</div><div style=""><br></div><div style="">I know all of this are not easy to measure (and may be out of scope of this discussion). But, it doesn't hurt to list things needed to make a project/product successful.</div><div style=""><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> let people do what they like more among these and let us also recognize them<br>
> for all their contributions. Let us celebrate their work in each monthly<br>
> news letter.<br>
<br>
</span>Good idea.<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
Gluster-devel mailing list<br>
<a href="mailto:Gluster-devel@gluster.org">Gluster-devel@gluster.org</a><br>
<a href="http://www.gluster.org/mailman/listinfo/gluster-devel" rel="noreferrer" target="_blank">http://www.gluster.org/mailman/listinfo/gluster-devel</a><br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Raghavendra G<br></div>
</div></div>