Technical organization goals

[dmethvin]

This is a discussion about the goals of the governance structure for the Foundation. Based on private email discussion there were many questions about the proposed structure so we're doing a reset and starting with the goals of this new structure.

Let's keep the issue focused on goals and ensure that everyone is on the same page. So for now, avoid critique of any existing proposed structure elsewhere in this repo and focus only on the overall goals below:

1. Separate the business aspects from the technical aspects of the Foundation.
   The Executive Director and Board of Directors focus on fundraising and strategic goals for the Foundation. The goal here is to create a project-oriented structure to provide help and mentorship to projects.
2. Establish a set of best practices for sustaining open source projects.
   This organization should create sample policies that provide guide rails and suggestions. Projects know their communities best and can tailor these practices to ensure their projects are sustainable.
3. Separate policy review from writing code and running a project.
   There often will be overlap in the people reviewing policy and those writing code or running a project. A separate process within the organization structure that focuses on policy review lets them take a step back and review the project’s overall health.
4. Have an independent group acting as an advocate for the project community.
   From the inside of a single project, it is often difficult to see opportunities for collaboration or know when the project has run into problems that could be solved by outside assistance. A group with a wider perspective can help.
5. Tailor involvement with the Foundation to fit project needs.
   Some projects have chosen the Foundation primarily to hold mature code bases that need few changes. Others are looking for help in managing growing code and communities. These projects have different needs and the Foundation wants to accommodate both.

[jzaefferer]

Separate the business aspects from the technical aspects of the Foundation.

I'd like to see more detail here. For example, currently the board decides what and when projects join the Foundation - is it a goal for the board to not deal with that anymore? A rough list of responsibilities that the board would like to let some form of technical group take over would help a lot.

[dmethvin]

For new projects, there will be questions that relate to finance so I think the board would need to be involved. The exact process would be something that needs to be worked out, but it's beyond goals.

[jzaefferer]

What about the rest of the board's responsibilities? Dealing with new projects was just one example, not my actual question. I need to understand how those are going to change, otherwise I find it impossible to judge any concrete proposals.

[dmethvin]

Let's work on these goals first. The odds are good that nobody can answer all your questions because those details haven't been worked out. I'm not expecting you or anyone to judge anything, but instead to help figure it out--when we get to that point.

[jzaefferer]

Fine. Looking at those 5 abstract goals, I agree with them!

[nzakas]

At a high level, these seem good. Just a few points I'd like to get clarification on:

This organization should create sample policies that provide guide rails and suggestions.

Can you define "this organization"?

Separate policy review from writing code and running a project.

Can you define "policy review"?

Have an independent group acting as an advocate for the project community.

This is the least clear goal for me. What does "independent" mean? How can someone not actively involved in the project be an advocate? And what does being an advocate mean?

[dmethvin]

Can you define "this organization"?

Whatever form of structure we all create above the projects. We'd like that structure to provide both new and existing projects a set of policies that can help them succeed. Many Foundation projects (especially the successful and thriving ones) will already be doing these things; we want to write them down so other projects can emulate them. Sorry the words are vague and abstract but I'm intentionally trying to avoid introducing specific terms like CB or TSC that imply some specific organization.

Can you define "policy review"?

This is related to the point above. It can be difficult for anyone or organization to judge itself objectively so the structure above can provide some outside perspective to help a project understand whether it's following the policies it set, meeting its goals, and serving its community.

How can someone not actively involved in the project be an advocate? And what does being an advocate mean?

There's the project, and there are the consumers/community around that project. Some projects may not be as good as others at serving the needs of their community. We want to be sure that Foundation projects are listening to their users, so this new structure will at times act as an advocate for the users of the project.

For instance, perhaps a project evolves to where is mostly run by a single person who rarely does much with it, won't give others commit access, and rejects most proposals for changes. The community is getting fed up with it and wants to fork the project to "solve" this. That is a place where some organization over the projects might try to intervene to improve things.

[nzakas]

Ok, let me try to restate what I think the goal is here.

At a high level, the goal seems to be ensuring some minimum acceptable level of project health for each project in the Foundation.

What we believe will achieve that is having a group or groups that:

1. Identifies best practices for running a successful open source project
2. Works with projects to implement those practices
3. Performs spot checks on projects to ensure they're following those practices
4. Intervenes when the project goes off the rails

Is that correct?

[kborchers]

@nzakas In general, yes, this is a perfect understanding of these goals. I would like to add a just a couple of points in addition to yours to again drive home that this is not some hierarchical structure that controls projects but instead is a group meant to inform them.

I would say that most "intervention" happens in number 3. By intervention, I would envision this mostly as a "Hey, we noticed this going on in your project and your policy says you would do this." I would think with that nudge, a project would want to self-correct from that point since they helped set those policies to ensure their health and longevity.

I would also say that number 4 should happen very rarely. A project would have to be really out of whack or looking to be in danger of hurting its community, losing its community or dying out before true intervention took place. What form that intervention comes in would again be defined by the projects that formed the groups to make those decisions but I would imagine it would be things like returning to mentorship or other constructive interventions. The hope here is that ever policy would have a positive focus and not be a "threat" hanging over projects as that is not an effective way to foster health and good will in and among the projects.

[nzakas]

Gotcha.

Then it sounds like what we're looking for is a "project health committee" rather than anything else. It also sounds like it would be important for whomever is on this committee to actually not be actively working on the project to provide more of the community perspective?

[kborchers]

Then it sounds like what we're looking for is a "project health committee" rather than anything else.

That seems like a pretty accurate description of the vision for these groups.

It also sounds like it would be important for whomever is on this committee to actually not be actively working on the project to provide more of the community perspective?

In the interest of keeping this focused on the goals outside of implementation, I'll hold off on responding to your last question until we transition back to finding a structure that fulfills these goals. That said, I think we did agree that some of the terms and the structural details of how groups are formed in the initial draft were not quite right and we can address those in the next version.

So outside of how we get there, do these goals make sense to everyone? On the email thread that was transferred to this public discussion, @dmethvin asked that everyone provide feedback by end of day today. Any other thoughts or questions from @nzakas or anyone else specifically about what the goals are that we should all be striving for in this technical org restructure?

[rxaviers]

FWIW, the discussion in this PR is a lot clearer to me compared to what was being discussed in the email. So, 👍 for this reset.

[kborchers]

It seems that based on the responses received, we can agree that these are good goals to have and that we can build our structure toward ensuring we meet these goals within our projects. I will move these goals into the README so they are not lost when the issue is closed and to ensure it is clear what the goals of this structure are when anyone reviews it. This issue will close when that change is merged. The discussion should now move to #4 as we build out the structure to meet these goals.