rprouse
commented
7 years ago I have always supported the idea of individual teams for each project and then a core team that manages the overall direction of the project, but lately I have become worried that we might be tilting at windmills. @CharliePoole and I started trying to put this in place around two years ago, but I don't feel we have been very successful. We have managed to recruit new members and we are spreading the load as best we can between the projects, but the core group seems to be working across all projects and a few of us are making the decisions for most projects.
I see the governance that we have come up with as a great ideal, but it doesn't seem to match the reality on the ground no matter how hard we have been trying. We also tend to recruit people for one team, but they usually like to work on several projects once they get involved.
I would be happy to keep the governance as we have set it and continue to strive for that ideal as long as we are comfortable with the fact that it doesn't match what we currently have. Just scan the NUnit Teams, the core team is on most and the other people are only occasionally active. If I want a PR reviewed, I find myself asking the core team most of the time.
We have managed to setup a few groups that are working like the GUI team and the TeamCity adapter, so maybe we should continue in that direction.
CharliePoole
jnm2
ChrisMaddock
@CharliePoole commented on Tue Jun 06 2017
I'm writing this as an question to be discussed by the Core Team, but we can transform it into an action item if we find there is something we need to do as a result.
I began breaking the old NUnit project into multiple pieces (framework, engine, etc.) for NUnit 3 because I pictured a future where different people could work on each project, establish their own road map, deliver on their own schedule. I wrote the governance docs, which the Core Team approved, with the same thing in mind. I feel we are ready to move on to the individual software projects and need to do so quickly to keep up our momentum.
However, in an email, Rob suggested that this is the wrong path to follow. Because I have been assuming that Rob would eventually become the Core Team Leader/Chair/Whatever-we-call-it, this was a bit disconcerting to me and has made me wonder if I could be wasting my time. The fact is, you guys are going to run the NUnit Project as you want to after I'm gone and that's OK. My working on these governance docs isn't intended to limit you but to expand the possibilities. If it's not working, then I should stop!
So the underlying question in this issue is should we proceed in the direction we have been going, with individual projects operating on a decentralized basis and with their own leads?
More to follow...
@CharliePoole commented on Tue Jun 06 2017
I'm excerpting the note from Rob that started me on this train of thought, hopefully not including anything that wasn't intended to be public...
"...we have been pushing project related teams for a long time now and don't seem to be getting much traction. I forget who said it in one of the governance reviews, probably you?, but I am beginning to wonder if we shouldn't just have one team that works on all the core projects and only setup smaller teams for secondary and contrib projects that we don't have time to maintain. Likely many of these will be one person teams.
"I think that because you and I have experience in all projects that we think that people can work in silos on one project. I am beginning to doubt that. I think it is important to understand how the framework and the engine work in order to work on the adapter for example. It would be nice if it was a clean API between the layers that people could work against without knowledge of what is inside the box, but I don't think we are there yet.
"Based on that, I wonder if the core team should be those developers who work on multiple projects and manage our core projects. We might want to include additional people who have been more active recently and I think the group should change over time as people's commitments allow. I think this might be more inline with the way you and I have been working for the last few years with a core group that changes over time?
"I had originally seen the core team as a group that stood outside of the development team that comprised of day to day contributors and respected people from the community that formed an advisory board. I am beginning to think that idea is overly ambitious. I think we have to embrace the realities that we face. Our team is very dynamic and changes constantly with people coming and going as they can commit time.
"Based on that, I doubt we will ever be able to fill all of the roles and teams we are envisioning in the governance documents and we shouldn't be chasing unattainable goals. I think all we need is a core group of committed leaders as you have been, and I strive to be, working with a changing group of people that commit what time they can when they can. It seems to me that this is the way that NUnit has always worked and it has worked fairly well in the past despite the ups and downs."
@CharliePoole commented on Tue Jun 06 2017
First comment: If Rob's ideas are right (or more to the point, if we decide to follow them) then I think we need to go back over the primary governance doc that describes the core team. As described, it is not a core group that runs the core projects - in spite of it's name. It's more like a board of directors.
So... let's decide what we think it should be.
I guess it's also an option to rename the Core Team we already defined and create a software project team that covers our core projects.
@CharliePoole commented on Tue Jun 06 2017
Second Comment...
The problem I see is that one person, Rob, is the software project lead for all of our core projects. In addition, he functions as the release manager for all of those projects. That doesn't seem sustainable.
In a sense, Rob is right that we always operated this way. But the past NUnit was much smaller than it is today and it was organized as one big project with everything released together. We have grown NUnit and also made structural changes so that it is currently more work to maintain. We did that in order to attract more people to do the work.
My concern is for the future. If all the core projects are actually one project, it seems as if people would be less likely to step up and volunteer to take that mega-project over when the time comes. It seems like it may be half-way reasonable to think that someone would take over the framework, rather than taking over the whole thing.
We can only guess about the future of course. But one indication we have is how you guys, today, feel about this. Would you see yourself taking over, for example, just the framework or just the console? Would you see yourself taking over "NUnit" entirely? My thought was that nobody in their right mind should want the "NUnit" job, which is why I started unbundling stuff.
@CharliePoole commented on Tue Jun 06 2017
Third Comment...
Here is a list of our software teams and their leads. I've skipped anything that doesn't do releases...
Framework Team - Rob Engine Team - Rob .NET Core Runner Team - Rob GUI Team - Charlie VS Extensions Team - Charlie on paper, but Rob has been doing it
IMO, the more a single person does, the more we are at risk in the future (see Truck Number). If we don't find different leads for each project, then we need permanent or rotating Release Managers for each one.
@CharliePoole commented on Tue Jun 06 2017
Fourth Comment...
Pushing ahead versus risk management in projects...
When a project has a long-established body of users and usage, you have to be careful not to break anything. On the other hand, you want to keep moving ahead, adding new features, supporting new platforms... all of which carry an element of risk.
In the (old) NUnit project, I always tried to be the guy who looked out for the risky stuff. NUnit was always somewhat conservative from its first days and I continued the tradition. We worried more about backward compatibility than about supporting the latest Microsoft innovation. Either in spite of that or just maybe because of it, we survived.
That's not the only approach. I've worked in other environments where I was the lead and I was pushing things ahead more rapidly than some people wanted to see. In those cases, I appointed somebody to be the guardian of backward compatibility, watch out for regressions, etc. That's the typical role of a release manager.
In releasing any piece of software, you need the push of innovation and the reserve of risk management. It's usually not reasonable, at least in my experience, to expect one person to have both things in mind at the same time. As we organize to release software, we should think about who is going to fill each role.
That's all from me for now on this.
@ChrisMaddock commented on Tue Jun 06 2017
There's a lot here, and I'm not sure I know the correct answer to any of it. Regardless - the below is my personal experience:
Project separation is difficult between the engine/framework - both bugs and features commonly seem to span both. I'm not sure I'd want to work on only one or the other - and constantly do 'half a job'. On the other hand, the GUI seems to be building up a small team working solely there - maybe that's a good model we should aim for? The VS adapter doesn't seem to have done the same - I wonder if that's because of the higher getting-started cost, or maybe the limited potential for new development.
On an 'advisory board' core team model vs 'software project team' - I see both perspectives, the Core Team and development team currently have a significant overlap. It would be nice to envisage that the core team would provide a more long-term oversight of the project, whilst the development team may possibly be more transient. Whether we're planning for a future that may not happen though, I don't know! That said, now we're here, I'm not sure it's a problem, the same people fulfilling the two roles, for the time being at least. Maybe someone could elaborate more there.
I personally wouldn't take over any of the larger projects on the basis of technical ability. I could however envisage the adapters/GUI being lead separately. The console/framework are more difficult to disentangle, as above, and I'd imagine it more difficult finding a team to work on either in isolation. However, I agree the size is intimidating - the size and level of activity of the framework alone would put me off - so I can't see that keeping the projects together would help that situation at all.
Fouth comment, pushing ahead vs risk management - I agree that's one to discuss, but perhaps a separate issue to what we're looking at here? At risk of polluting this one, my personal thoughts are that (looking more recently) - I see the importance of moving with what's new. Rob's been bit recently with the dotnet-test-adapter, however it would still be my opinion that that was a necessary investment, in order not to fall by the wayside with the move to .NET Standard/Core. Of course, this all becomes more difficult when we have limited resources - but again, as an open source project, this will always be driven to some extent by what people are interested in working on - rather than what would perhaps form the strongest choice if we were working to sell NUnit. 😄 On backwards compatibility - I think NUnit's standard is generally very high, however, we do need to make a decision at the points where backwards compatibility begins to affect out ability to support future platforms, to a suitably high standard. I'm tempted to say that should be the area of a project lead - although I'm aware that role is currently repeated by one or two people.
@CharliePoole commented on Tue Jun 06 2017
@ChrisMaddock I've noticed that you seem to gravitate toward issues that cross the boundaries and that you like to work on all parts of it... stuff like attachments for example. I think there are lots of people who prefer that, although it's hard because you have to be familiar with a lot of different tech.
OTOH, I would say that the majority of the stuff we do is limited to a single project: New assertions, constraints, bug fixes in the framework'; location of extensions in the engine; reporting in the console runner. So it could be that that's the less interesting stuff or that the integration issues float to the top because they cause us so many problems.
Regarding advisory board versus board of directors model: I had hoped we were past that, having already made the decision. If we are not, however, I'd like to know because it's frustrating to be assuming something as decided and realize that not everyone has got there yet.
I agree that the question of pushing ahead versus risk management is somewhat separate from this. I put it in there because in my mind you can't be both and I think anybody putting himself forward as a lead for a project has to decide which side of the equation he falls on and make arrangements for the other side. I say that having given up working on exciting new stuff in many areas for years because I was the guy in charge with a role to fulfill.
I agree 100% that we have to figure out a way that people can work on the things that turn them on!
@jnm2 commented on Tue Jun 06 2017
Even though ideally we'd have more people, I also haven't yet understood why it is a problem for members of the core team to double as members of development teams. What specifically would be gained by undoing the current decision?
@CharliePoole commented on Tue Jun 06 2017
I think this line of discussion goes back to ideas that were discussed as much as two years ago. Since you are new to the discussion, you may have to put up with feeling a little lost part of the time. :smile:
I created the Core Team originally to be those people with write access to all our repositories. They were the main people responsible for NUnit in an operational way but they didn't function as any kind of committee.
About 18 months ago, I started trying to make the Core Team into a sort of governing body for the overall project, but still comprised of key developers and still all having write access to everything. At around the same time, we discussed some options like having an additional advisory board of users and/or including such people in the core team but in a purely advisory, non-operational role. I didn't go that way because I don't think a group or team that has people with different levels of authority on it works well - that is, if you're advisory it should be clear that's what you are and also whom you are advising. Personally, I don't see a big need for an advisory group, but if the core team decided it wanted one, I'd expect it to be separate and not grant any access to our repos.
Reviewing all the notes, I don't think anyone who has mentioned an advisory group is pushing for the Core Team to be purely advisory.
The reason the Core Team has meant different things at different times is that I have never been able to come up with a better name. Board of Directors is too corporate for me and also implies no direct operational role.
I think what is actually the point of this issue is whether the core team should actually run projects as a body or just be a last resort for resolving issues within or between projects. In the docs we approved, the running of projects is left too Software Project Teams and especially the leaders of such teams. If that's what we want to do, then the next step will be to go on and decide who the leaders of each project should be. If not, then I think we rewrite the docs so they describe what you guys actually want to do.
Talking about this with my wife, she asked if it was possibly to difficult for devs to think at the broad level of future organization. I acknowledged it could be for some people who are not used to it - who don't get to do that in the companies where they work. But I added that the subject is something that you are all experts in: how you want to work.
You guys on the Core Team are the most active developers of NUnit we have. So if none of you think you will ever want to take responsibility for one of the software projects, then we should probably be looking for another alternative. I just don't want us to decide without asking you.
BTW, I did try to define the responsibilities of a software project leader in the governance doc. Folks may want to reread that.
@CharliePoole commented on Wed Jun 07 2017
Apologies for having created this in the wrong place! I'll move it.