Re: [eclipse-dev] [ide-dev] Development Process was Re: Why we dropped E

[Miles Parker <miles.parker@xxxxxxxxxxx>]

Now, I will move this back to eclipse dev because I think this is an important discussion for all projects. And Konstantin, please don't think that argumentative stuff below is aimed at you.. You've just given me the excuse to rant a bit about something I've felt like saying for quite a while now. :)

"This is making an assumption that all changes are reviewed, which doesn't
> hold universally. I know that some projects operate that way, but many only
> review contributor changes."

I was reading you to mean that "only review contributor changes" *but don't review non-contributors* (whatever that would have meant), but what you meant was "not all committer changes are reviewed". I know my assumption is wrong, but I guess I was thinking that projects would be migrating away from not reviewing committer changes. Because that is the only sensible and fair thing to do, even if we don't all realize it yet.. :)

> If you are saying that you are troubled that not everyone is using Gerrit or
> reviewing all changes, then that's a completely separate development process
> discussion that will just derail this thread. It would be sufficient to
> recognize that all projects do not use the same development process.

It won't derail the thread, it was the entire point of this thread! :D How we handle process of committers and reviews is critical to how well we handle the innovation challenges that Eclipse is facing right now. And we're doing it wrong a lot of time. Every Eclipse project could improve radically in terms of how we respond to "outsiders" contributions.

If we see Gerrit as a neat new tool to prevent outside contributors from wrecking our (perceived good) quality  -- some kind of gateway -- then that's an *abuse* of Gerrit. The unmistakeable message is "we think your code probably stinks, and we know that our code never does." It means that we aren't even willing to play by the same set of rules. We'd all like to think that this is all in the service of protecting the quality of our precious toolsets, but it's not. To assume that because we've been working on a project for a long-time that somehow we're not going to make the same kind of mistakes that other seasoned developers would is simply arrogant. Sure you have to learn the idioms and the APIs, etc.. and it can be a PITA to work w/ someone who isn't familiar w/ them, and yes, I understand that it's a real problem to have to deal with contributions that just aren't up to snuff or that don't fit in with development priorities or that create new maintenance burdens for the project -- but if we aren't willing to put effort into that, what exactly is it that makes us a community?

We keep talking about having to have a level of trust to allow anyone to get anywhere near our code, but we never think about the trust that *we* have to create for users that their contributions will actually get somewhere. I'm sorry, but I think it's time to say it -- we have a culture of arrogance at Eclipse. It's almost like some kind of primitive guild system we've built ourselves. Like working at a law firm or something -- "we jumped through these hoops, now it's your turn." The process becomes its own reward.

So to bring it back to the question at hand, why would a company want to invest in that effort knowing that there is a good chance that their contributions would be ignored? IMO, we need to level the playing field and evolve toward having all projects commit to having the resources to do reviews of outside work just as we expect them to do bug triage, release train maintenance, etc.. and above all to follow the same basic review process, committer or not.

-Miles

On 2013-09-24, at 2:50 PM, Konstantin Komissarchik <konstantin.komissarchik@xxxxxxxxxx> wrote:

>> Hmm..I'm not sure we really make a hard distinction between "contributors"
> 
>> and "non-contributors" I'm not even sure how you would formalize that. 
> 
> The distinction between a committer and a contributor is well defined. Those
> are the only roles that I referenced.
> 
>> But it is a bit troubling to hear that some review submissions aren't
>> actually even reviewed.
> 
> If you are saying that you are troubled that not everyone is using Gerrit or
> reviewing all changes, then that's a completely separate development process
> discussion that will just derail this thread. It would be sufficient to
> recognize that all projects do not use the same development process.
> 
>> So you're not saying "part-time" vs. "full-time" as in 40 hours of work, 
>> but as in long-term commitment? I think having a requirement that for 
>> example a committer actually be employed to do the work that they're doing
>> would not be fair, but I don't think that's what you're suggesting.
> 
> No, I don't use "full-time" to mean 40 hours of work on the project, but
> rather consistent and meaningful engagement. What that means in detail will
> differ from project to project. For instance, there is a contributor on
> Sapphire with many high quality patches to his name, but a track record of
> sporadic engagement. A flurry of activity, then silence for many months.
> That doesn't instill confidence that he will keep sufficiently up to date
> with the project for his contributions to be trusted without further review,
> so no commit rights and a longer path to getting contributions merged.
> 
>> [snip] I was going on the assumption that people were used to reviewing
> other
>> people's work *w/in* a project. That's how we do it at Mylyn.
> 
> A bad assumption. I would venture to guess that most projects don't operate
> this way and more to the point, unless something changed recently, the core
> projects under discussion in this thread certainly don't operate this way.
> 
> - Konstantin
> 
> 
> 
> -----Original Message-----
> From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] On
> Behalf Of Miles Parker
> Sent: Tuesday, September 24, 2013 2:19 PM
> To: Discussions about the IDE
> Subject: Re: [ide-dev] Development Process was Re: Why we dropped Eclipse in
> favour of IntelliJ | Java Code Geeks
> 
> 
> This discussion is interesting. I'm almost tempted to put it back over on
> eclipse-dev, but I guess I won't confuse thigns further. :D
> 
> On 2013-09-24, at 1:47 PM, Konstantin Komissarchik
> <konstantin.komissarchik@xxxxxxxxxx> wrote:
>> 
>> This is making an assumption that all changes are reviewed, which 
>> doesn't hold universally. I know that some projects operate that way, 
>> but many only review contributor changes. Once a committer has earned 
>> access, they are allowed to merge changes without prior review.
> 
> Hmm..I'm not sure we really make a hard distinction between "contributors"
> and "non-contributors" I'm not even sure how you would formalize that. But
> it is a bit troubling to hear that some review submissions aren't actually
> even reviewed.
> 
>> 
>> The part-time vs full-time distinction comes into play when it comes 
>> to earning commit rights. Most projects use dual criteria for 
>> committers: (a)
> 
> So you're not saying "part-time" vs. "full-time" as in 40 hours of work, but
> as in long-term commitment? I think having a requirement that for example a
> committer actually be employed to do the work that they're doing would not
> be fair, but I don't think that's what you're suggesting.
> 
>> sufficient volume of high-quality work, and (b) consistent involvement 
>> over a certain span of time. The reason that you have (b) is that you 
>> cannot trust a committer that checks out for six months at a time to 
>> keep tabs on project development and be able to continue to make safe 
>> changes. Their contributions are still welcome, but need to be reviewed.
>> My original point is that if you fund a developer to focus on say 
>> Platform and JDT, there shouldn't be a problem in achieving 
>> consistency of involvement that many projects are looking for. That 
>> gets you commit rights and the quicker path for merging changes.
> 
> I think all changes should be reviewed! To me, this is the big sea change
> that Gerrit represents. As I said in a tongue-in-cheek blog -- "That's
> because -- when implemented fully and correctly -- Gerrit makes it every bit
> as annoying for Committers to get code in as it is for Contributors." :D
> (http://milesparker.blogspot.ca/2013/01/adopting-gerrit.html)
> 
> But I'm glad you mentioned that, because I guess I was going on the
> assumption that people were used to reviewing other people's work *w/in* a
> project. That's how we do it at Mylyn. I wouldn't really think of merging
> code unless I got a +1 from at least one other committer, or it was
> something really trivial. (But maybe that's just based on my commit
> track-record. :P And as we all know, the dumbest mistakes usually involve
> "that one line of code with a simple error".) When people are used to
> reviewing other people's code as part of their day to day work effort that's
> a very different thing from asking someone to do a task (reviewing) that is
> totally divergent from the normal development process.
> 
> So personally, I think all projects should be moving to universal review.
> That might seem like imposing more work, but it improves code quality and
> often improves community as well. So I think this points to a real
> opportunity to for projects to look at their own processes and find ways to
> make them more open and democratic. 
> 
> -Miles
> 
> 
>> 
>> - Konstantin
>> 
>> 
>> -----Original Message-----
>> From: ide-dev-bounces@xxxxxxxxxxx [mailto:ide-dev-bounces@xxxxxxxxxxx] 
>> On Behalf Of Miles Parker
>> Sent: Tuesday, September 24, 2013 1:25 PM
>> To: Discussions about the IDE
>> Subject: [ide-dev] Development Process was Re: Why we dropped Eclipse 
>> in favour of IntelliJ | Java Code Geeks
>> 
>> 
>> Mickael , You're right, length of time for reviews and overall EDP 
>> friction is a _big_ issue. That isn't going to get fixed by somehow 
>> giving developers a special guarantee or review status. For all the 
>> reasons you mentioned and more, that would be a violation of Eclipse 
>> principles -- not to mention impossible to manage. You should be 
>> offended by this if you saw it happening! (And believe me, there 
>> aren't necessarily special favours just because you're an employee of 
>> a firm associated w/ a project. To the contrary. :) Though member 
>> agreements do help with the "paper"work and
>> process.) So, I think tying performance on feature objectives to fast 
>> turn-around on reviews is wrong. The catch-22 is you cannot run a 
>> business where your deliverables are hostage to a process you don't 
>> have control over.
>> 
>> So what to do? You of course try to get it merged during the period of 
>> performance, but you *don't* guarantee it. Delivery is the work that 
>> has been done, not that it has been reviewed and merged. That is a 
>> difficult thing to wrap one's head around, but it comes down to trust 
>> between the contracting developers and the sponsor, and that can only
> develop over time.
>> You need to establish strong long-term relationships between companies 
>> willing to sponsor specific development efforts and those able to 
>> execute on them.
>> 
>> WRT Developer vs. Review time, you need both, but in my experience you 
>> aren't going to get corporate sponsors to support reviews. You 
>> *should* get them to include reviews as a kind of overhead. But time 
>> for reviews has to already be built in to the project somehow. This is 
>> a chicken-and-egg thing , and so I can see the attraction of the idea 
>> of having the foundation pay for reviews, but I don't really see how 
>> to make that work. So *before* expecting sponsorship on a particular 
>> project you need to ensure that the current committers are committed 
>> (no pun intended) to reviewing outside contributions, to have a track 
>> record of openness, and to have a clear path to committer status in a 
>> reasonable amount of time *if that's the appropriate thing, and it 
>> doesn't always have to be*. The first part is the hard one -- Reviews 
>> take up a lot of time, and so it's a hard ask to have someone drop 
>> their priorities in order to look at code that they're uncertain about 
>> and that could be motiva  ted on a different set of priorities. And 
>> note that committers are already having to do a lot of work like build 
>> management, bug triage, etc., etc. that isn't all that sexy so this 
>> just further reduces that bandwidth for doing cool stuff. It's not a 
>> small ask. :) Bottom line is the one thing we *can't* do is just say 
>> "here Stephan (to pick on the JDT team :)), here's some more code for you.
> Can you review it next week so I can get paid?" Another Catch-22.
>> 
>> Practically, I think it means that the organizations that are 
>> currently deeply supportive of the project in question also be in on 
>> the discussion about the work as early in the cycle as possible and 
>> that some way is found to support current committers. I suspect that, 
>> ironically, it is easier to do for a project like Mylyn with a small 
>> company taking the leadership role, and where we see the importance of 
>> the overall investment, and a large one like IBM that doesn't see a 
>> connection between community building and the outcome and wouldn't 
>> have a way to handle sponsorship even it it were offered. (And who 
>> would offer it?) So I think part of the issue the JDT issue is actually
> structural.
>> 
>> But, while I would never say that this is easy to manage (it can be 
>> really painful at times), it *is* possible, and the potential rewards are
> worth it.
>> Gunnar and I -- and probably many others on this list -- here have 
>> experience with this and would be happy to share whatever we can about 
>> making these relationships work. It isn't always easy, but it can be 
>> really rewarding both for the sponsor seeing actual progress on things 
>> they care about, and developers being able to work on stuff that they know
> matters.
>> 
>> Konstantin WRT to part time vs. full-time committers, again, I don't 
>> honestly think it really matters all that much -- or it shouldn't and 
>> if it does we should work to fix it. With Gerrit, it is much more of 
>> an equal playing field. That might not be quite true in platform yet, 
>> but with Mylyn at least the process is really a difference of degree 
>> rather than kind these days. e.g. it might take a bit longer and 
>> reviewers might be a little (heh) more painstaking on the review but 
>> the overall process for commiters and non-committers is fundamentally 
>> the same. Really! :D
>> 
>> cheers,
>> 
>> Miles
>> 
>> On 2013-09-23, at 8:53 AM, Mickael Istria <mistria@xxxxxxxxxx> wrote:
>>> 
>>> The current issue with the contribution model, especially for 
>>> platform, is
>> that there is no guarantee that even by doing the work, a feature will 
>> get reviewed, approved or merged in time. Without this guarantee, one can
> see
>> contributing as a potential waste and     will be reluctant to start a
>> contribution work. I don't think companies wish to pay developers to 
>> do work they can do by themselves. What they wish is more ability to 
>> make things happen.
>>> 
>>> I don't get why paying someone working for the Foundation would help 
>>> in
>> getting stuff done in Eclipse faster than contributing code directly. 
>> It would appear to me that if we go for a "let's pay the Foundation for a
>> feature" mode, it means that this developer will     need to have
> super-fast
>> reviews of his patches and a very quick feedback/merge loop in order 
>> to honor the contracts. But why would someone in particular have that 
>> privilege of fast review? In a community, any contributor should start 
>> with the same status based on merit, independently of its employer or 
>> contract. If someone gets hired by organization X (may it be the 
>> Foundation or something else) and gets its Gerrit patch reviewed 
>> before mine just because of his employer, I would find it almost
> insulting.
>>> There is progress on that side with Gerrit and so on, but it's still 
>>> a
>> long time to wait for an answer. I understand that current committers 
>> on Platform have many things to do and that they're doing there best 
>> to find time to review, it's not a personal accusation.
>>> 
>>> 
>>> So overall, those 3 points lead to the idea that what is needed isn't 
>>> more
>> developers, or a paid developer to do some things, but rather more 
>> reviewers that will shorten feedback loop and speed up the heartbeat 
>> of the project. I may be wrong, I think that's what Linux has been 
>> paid for at the Linux
>> Foundation: now writing code, but reviewing it.
>>> But it's easier said than done: let's say the Foundation goes for 
>>> hiring a
>> reviewer for Platform, or JDT; there are concretely a very few people 
>> able to handle that task. Would anyone want to take this role?
>>> --
>> 
>> 
>> On 2013-09-23, at 9:02 AM, Konstantin Komissarchik 
>> <konstantin.komissarchik@xxxxxxxxxx> wrote:
>> 
>>> The assumption behind having Eclipse Foundation hire developers is 
>>> that
>> they would concentrate on a handful of core projects and as the result 
>> of this full time focus rapidly earn the committer rights through the 
>> usual process. The dynamic for part-time contributors is quite different.
>> 
>> 
>> Miles T. Parker | Tasktop Labs | Tasktop Technologies
>> skype: milestravisparker  | web: http://tasktop.com  | blog:
>> http://milesparker.blogspot.com
>> 
>> Committer: Eclipse Mylyn Reviews, R4E, Virgo
>> Lead: Eclipse Mylyn MFT, AMP
>> 
>> Are you passionate about innovation and excellence and interested in 
>> joining our team? Tasktop, voted one of the Best Companies to Work for 
>> in British Columbia, is hiring!
>> 
>> _______________________________________________
>> ide-dev mailing list
>> ide-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ide-dev
>> 
>> _______________________________________________
>> ide-dev mailing list
>> ide-dev@xxxxxxxxxxx
>> https://dev.eclipse.org/mailman/listinfo/ide-dev
> 
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ide-dev
> 
> _______________________________________________
> ide-dev mailing list
> ide-dev@xxxxxxxxxxx
> https://dev.eclipse.org/mailman/listinfo/ide-dev