Remove roadmapping as an LT responsibility

[btm]

As discussed at the 2015-02-19 meeting, LTs won't often have resources to drive
a roadmap themselves, and so it's confusing to expect them to provide one.

[jonlives]

👍

[thommay]

👍

[jaymzh]

👍

[nathenharvey]

👍

[coderanger]

:-/ We shouldn't remove this without adding something to offset it. Someone should be responsible for the roadmap.

[btm]

@coderanger the project lead does, a few lines up "Provides vision and roadmap"

[ranjib]

@btm across all components? it will be hard. LTs will also reduce to arbitrator . Also Resolves disputes within their component will influencing the future direction/road map. If the fear is that LT's wont have enough time, we can make it optional, Project lead, the de-facto catch all, can take care of the components that dont have roadmaps from their LTs. But keeping it optional will allow some distribution of the roadmap efforts,

[btm]

I guess I don't get what kind of roadmap we expect LT's to produce when they're not part of team of people who are spending a significant account of time working on Chef. The best they can do is observe the current PRs and say what's in flight, but a roadmap should give us a view out a quarter or two. You've got to have a lot of developer hours planned/contracted/employed to provide a roadmap that's going to have a chance of coming to fruition.

I happen to be able provide a roadmap for Windows, because I happen to be the lead of an engineering team at Chef Inc that is working on Windows and I need to do that anyway. But that roadmap would be just what my team and maybe other teams in Chef Inc. are working on.

But for example @jonlives as Lt. of the Enterprise Linux component probably doesn't have developers working on Chef. So we're effectively discouraging people outside of Chef Inc. to be LTs by requiring them to make Roadmaps, which we definitely don't want.

[coderanger]

I know for a fact that @adamhjk doesn't have the cycles to produce an in-depth public roadmap because if he did we would already have one and wouldn't be having this conversation. If the LTs aren't driving things, they shouldn't exist. If that means that people for whom Chef is not a full-time job (paid or otherwise) cannot be LTs then we should face that rather than make it a ceremonial position. If the reality is just to water things down to the level of an authorized code review team for each component then so be it, but the structure should reflect that.

Yes this means people outside the company might be telling people inside the company what to work on, I'm 👍 👍 👍 on that.

[adamhjk]

I'm more than happy to make it optional. What happened here was we asked the simple question:

"What is keeping people from being LT level decision makers?"

And the response was "we're worried about the time commitment to create a road-map". The RFCs, and the processes we codify, are there to help us run the project in the open, in a transparent way, and welcome more people into the decision making process for Chef. When I verbally removed that requirement, we had multiple LTs sign up.

What I think we really need is just a way to talk about what we mean by road-map, and how we will generate it. I suspect what most users actually want is a list of what new things are coming up, both in the next minor and major version of Chef. That list needs to change over time, because priorities shift, etc etc.

What if we said the LTs participate in a road-map process for Chef? We can figure out when/where/how to do that.

For the record, nobody is going to tell anybody what they must work on in our open source project. What we can do is come to an agreement on what we want, and some shared understanding of who feels like they'll have the time and effort to produce it. End of the day, though, we're here by choice - and the work gets done or it doesn't.

[coderanger]

A responsibility of being a decision maker is communicating those decisions effectively. A concrete form of that is a list of things planed for the future, but there are plenty of others. As long as the LTs still understand that the communication is their responsibility I'm happy for it to be in just about any form that gets the job done.

On the "telling people what to do", I don't mean that the LTs should be barking orders but if you (as CTO) say "we would like to put person X on fixing up RHEL for a week" I would totally expect the RHEL LT to be the person that comes up with the tasks that will be their job for that week, even if that LT doesn't work at Chef Software. You are under no obligation to ever do that as your employees are your resources to use as you see fit, I just don't want that dismissed on the basis that it would involve someone outside the company in normally-internal processes ("normal" from the PoV of a traditional software company).

[danielsdeleo]

I think this is a thing that will emerge over time. It took us a while to get our first non-CHEF maintainers and LTs, and it will take us more time to get enough folks doing development independent of Chef Software initiatives for those folks to create their own priorities with the resources to achieve them. As I see it, that means the first few road maps might be something like "q2: get more maintainers for $area_of_responsibility so we can have a big enough community to work on initiatives," and I think that's fine as we grow from where we are to where we want to be.

[adamhjk]

I'm not dismissing the idea that folks who work for Chef Software would work on things that make sense to the LTs. I am rejecting your phrasing completely. If there are issues with an area that require attention, as a project, we put the resources we can against those areas. They may be Chef Software employees, they may not be. No extra burden applies to us than to any other open source contributor, though - I'm not going to say "Go do what Noah tells you for a week" to an employee, any more than I would say it to Jon Cowie (who doesn't work for me, for those of you who don't know who Jon is.)

An important piece of where we are now, as a project, compared to where we have been, is simply the fact that we're having these conversations, in public, with identified people who are empowered to make decisions. Lets come up with a way that feels legit to have some visibility into where we are heading, make sure it includes the people who have volunteered to lead the project, and see if we like the outcomes. If we do, great. If we don't, we'll iterate.

[stevendanna]

(Disclosure for those who don't know all the minor characters in the play: I am a Chef Software, Inc Employee. Most of my work on Chef has happened outside of my normal work responsibilities).

I'm 👍 on removing the "Road map two quarters out" language. I'm also 👍 on replacing it with language that talks more generally about communicating long-term goals or participating in a project-wide roadmap discussion.

The current language does not accurately reflect how we (or maybe just I) would like the community to operate. An LT doesn't control resources other than their own labor. They can drive a subsystem towards a particular goal by:

1. using their own labor,
2. communicating their goals and persuading others that those goals are worth working on,
3. reviewing contributions and offering advice in line with their goals
4. veto'ing contributions that would undermine those goals.

Yes this means people outside the company might be telling people inside the company what to work on, I'm 👍 👍 👍 on that.

For the record, nobody is going to tell anybody what they must work on in our open source project.

I would totally expect the RHEL LT to be the person that comes up with the tasks that will be their job for that week

Why? The LT would have the same power with respect to Chef Software contributions as any other: The ability to veto them if they are totally out of line with what she wants for the subcomponent.

[jaymzh]

Well said, @stevendanna. I agree completely.

To elaborate on what @danielsdeleo said, I think figuring out how non-ChefInc LTs are going to set goals or direction is going to take a long time to shake out, but lowering the barrier to being an LT is a good thing. Also, it's not clear all areas need "long term planning" in that sense. Look at Linus - he doesn't have a roadmap for the next 2 months of Linux. All he does is settle disputes and occasionally review code. There's probably areas in Chef where that sort of LTing is the most useful thing possible. There may be other areas that are hurting and need a plan for improvement thus making a set of goals or something road-map-ish more of a useful endeavor. Even in that case, there's a few different possibilities. It could be an area with a small niche userbase entirely written and maintained by community... or it could be something that ChefInc is wanting to pour some resources in because their customers and/or the community is hurting because of it. In the former case that LT is communicating some goals to maybe 2 contributors, but in the latter case, they are probably working with ChefInc much more directly to set goals and split up work. We need to allow flexibility to allow LTs and Ms and ChefInc management to find the right balance for each subsystem.

Also @adamhjk I love, "Lets come up with a way that feels legit to have some visibility into where we are heading, make sure it includes the people who have volunteered to lead the project, and see if we like the outcomes" - 👍 👍 👍

[jonlives]

I also agree wholeheartedly with @stevendanna's phrasing.

One of my main concerns with quarterly roadmaps being the responsibility of LTs (and the reason I had not previously volunteered to be one) was the time commitment necessary to do so - unlike many Chef Inc employees, many third-party maintainers like myself are not solely focussed on working on Chef, and have extensive demands on their work-day time and priorities outside of this community.

As the CentOS LT I'm not looking to have power or control over those working on CentOS components, I'm looking to resolve any disputes that might arise and communicate such goals as I have.

Take for example the multi-package stuff that @jaymzh contributed to the last version which touched on the yum package provider - that was something that greatly improved the package resource for him. Was it something I would have prioritised as a goal of mine? Perhaps not. But that's the point - if the LT becomes the arbitrator of what's worked on for their components, you only get improvements that matter to that LT.

[adamhjk]

This is +1 for merge. We are going to make this a topic at the community summit pre-chefconf, and come up with the lightest weight possible process to make a public roadmap. Current thought is add a Roadmap.md file, which the LTs can merge to at will.

@chef/rfc-editors take it away.

[btm]

In further discussion in IRC @danielsdeleo requested some language like "provides guidance on future direction for their subsystem" and I promised to present an initial ROADMAP.md RFC draft right away.