[ide-dev] Development Process was Re: Why we dropped Eclipse in favour o

[Miles Parker <miles.parker@xxxxxxxxxxx>]

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 motivated 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!