<p dir="ltr"><br>
On Dec 10, 2013 2:37 AM, "Robert Collins" <<a href="mailto:robertc@robertcollins.net">robertc@robertcollins.net</a>> wrote:<br>
><br>
> On 6 December 2013 21:56, Jaromir Coufal <<a href="mailto:jcoufal@redhat.com">jcoufal@redhat.com</a>> wrote:<br>
><br>
> ><br>
> > Hey there,<br>
> ><br>
> > thanks Rob for keeping eye on this. Speaking for myself, as current<br>
> > non-coder it was very hard to keep pace with others, especially when UI was<br>
> > on hold and I was designing future views. I'll continue working on designs<br>
> > much more, but I will also keep an eye on code which is going in. I believe<br>
> > that UX reviews will be needed before merging so that we assure keeping the<br>
> > vision. That's why I would like to express my will to stay within -core even<br>
> > when I don't deliver that big amount of reviews as other engineers. However<br>
> > if anybody feels that I should be just +1, I completely understand and I<br>
> > will give up my +2 power.<br>
> ><br>
> > -- Jarda<br>
><br>
> Hey, so -<br>
><br>
> I think there are two key things to highlight here. Firstly, there's<br>
> considerable support from other -core for delaying the removals this<br>
> month, issue. I'll re-evaluate in Jan (and be understanding then as there<br>
> is a big 1-2 week holiday in there).<br>
><br>
> That said, I want to try and break down the actual implications here,<br>
> both in terms of contributions, recognition and what it means for the<br>
> project.<br>
><br>
> Firstly, contributions. Reviewing isn't currently *directly*<br>
> recognised as a 'technical contribution' by the bylaws: writing code<br>
> that land in the repository is, and there is a process for other<br>
> contributions (such as design, UX, and reviews) to be explicitly<br>
> recognised out-of-band. It's possible we should revisit that -<br>
> certainly I'd be very happy to nominate people contributing through<br>
> that means as a TripleO ATC irrespective of their landing patches in a<br>
> TripleO code repository [as long as their reviews *are* helpful :)].<br>
> But thats a legalistic sort of approach. A more holistic approach is<br>
> to say that any activity that helps TripleO succeed in it's mission is<br>
> a contribution, and we should be fairly broad in our recognition of<br>
> that activity : whether it's organising contributed hardware for the<br>
> test cloud, helping admin the test cloud, doing code review, or UX<br>
> design - we should recognise and celebrate all of those things.<br>
> Specifically, taking the time to write a thoughtful code review which<br>
> avoids a bug landing in TripleO, or keeps the design flexible and<br>
> effective *is* contributing to TripleO.<br>
><br>
> We have a bit of a bug in OpenStack today, IMO, in that there is more<br>
> focus on being -core than on being a good effective reviewer. IMO<br>
> that's backwards: the magic switch that lets you set +2 and -2 is a<br>
> responsibility, and that has some impact on the weight your comments<br>
> in reviews have on other people - both other core and non-core, but<br>
> the contribution we make by reviewing doesn't suddenly get<br>
> significantly better by virtue of being -core. There is an element of<br>
> trust and faith in personality etc - you don't want destructive<br>
> behaviour in code review, but you don't want that from anyone - it's<br>
> not a new requirement place on -core. What I'd like to see is more of<br>
> a focus on review (design review, code review, architecture review) as<br>
> something we should all contribute towards - jointly share the burden.<br>
> For instance, the summit is a fantastic point for us to come together<br>
> and do joint design review of the work organisations are pushing on<br>
> for the next 6 months : thats a fantastic contribution. But when<br>
> organisations don't send people to the summit, because of $reasons,<br>
> that reduces our entire ability to catch problems with that planned<br>
> work : going to the summit is /hard work/ - long days, exhausting,<br>
> intense conversations. The idea (which I've heard some folk mention)<br>
> that only -core folk would be sent to the summit is incredibly nutty!<br>
><br>
> So what does it mean for TripleO when someone stops being -core<br>
> because of inactivity:<br>
><br>
> Firstly it means they have *already* effectively stopped doing code<br>
> review at a high frequency: they are *not* contributing in a<br>
> substantial fashion through that avenue. It doesn't mean anything<br>
> about other avenues of contribution.<br>
><br>
> Secondly, if they do notice something badly wrong with a patch, or a<br>
> patch that needs urgent landing, they can no longer do that<br>
> themselves: they need to find a -core and get the -core to do it.<br>
><br>
> Thats really about it - there is no substantial impact on the core<br>
> review bandwidth for the team (they were already largely inactive).</p>
<p dir="ltr">+1</p>
<p dir="ltr">Very well put, as you said this is a larger openstack issue, hopefully we can fix this on the larger openstack scale and not just in tripleo.</p>
<p dir="ltr">><br>
> So, how does this apply to you specifically, and to the other Tuskar<br>
> UI folk who've been focused on Horizon itself and other things<br>
> recently....<br>
><br>
> If you add a -1 to a patch, it should be treated with much the same<br>
> consideration as one from me: we all want to get good code in, and the<br>
> union of opinions should be fairly harmonious.<br>
><br>
> If you +1 a patch saying 'the design is great', it helps other folk<br>
> worry less about that, but we still have to care for the code, the API<br>
> implications etc.<br>
><br>
> If you (I'm speaking to everyone that I proposed in the 'should we<br>
> remove from -core?' section are planning on staying about the same<br>
> level of activity w.r.t. code review, then I don't think being in<br>
> -core makes a lot of sense. We're pretty up to date on reviews - we<br>
> have very little backlog and code quality landing is pretty good. Even<br>
> if one of you individually wrote 90% of the new Tuskar-API code, if<br>
> you're not reviewing *other peoples code* enough to keep up to date...<br>
> then being in -core doesn't make sense. Writing code and reviewing<br>
> code are separate contribution pathways, and though obviously there is<br>
> considerable crossover it's entirely possible to be good at one and<br>
> not the other, or just to do a lot of one and not the other. *And<br>
> thats OK*.<br>
><br>
> So all that said, I think the vote summary is:<br>
>  - Ghe into core<br>
>  - the proposed removals held for a month<br>
><br>
> And we'll re-evaluate in Jan.<br>
><br>
> -Rob<br>
><br>
><br>
> --<br>
> Robert Collins <<a href="mailto:rbtcollins@hp.com">rbtcollins@hp.com</a>><br>
> Distinguished Technologist<br>
> HP Converged Cloud<br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</p>