Create governance document about community HOT 15 OPEN

More questions I have:

• how do projects get added to the org? (who decides what gets added)
• do projects ever get removed?
• does each project need some level of maintenance? do there need to be declared maintainer(s)?
• does maintaining / contributing to one project give push access to all projects?

from community.

I created

• Create project acceptance document
• What support should a maintainer/project expect from prometheus-community?

from community.

And opinions I have:

using Prometheus governance as a starting base

The Prometheus project governance may be too structured for a semi-open community org. We can refer to it (and thus, prometheus-team) as the arbiter for disagreements in this org though.

prometheus-team feel the need to retain final call in case of disagreements

We need to retain final control over what happens under the Prometheus name.

do there need to be declared maintainer(s)?

yes

level of involvement we would mandate to join this org as a member?

nomination by a maintainer ("I want this person to be able to contribute to the project I maintain")

how do projects get added to the org

proposal on prometheus-developers, final call with the team, default to "yes" (but what would be causes for a no?)

do projects ever get removed

maybe if they're going unmaintained to the point of being dangerous. otherwise they can still hang around even if new features aren't getting merged, until someone who wants their feature merged gets annoyed enough to pick up maintainership.

push access to all projects

we'll have to try this either way. if we start open, but have too much trouble with cross-project vandalism we need to close it; how would we do that? if we start closed, but it becomes too much hassle to get everyone access to everything they want to work on, opening up would be quite easy. on the other hand starting closed may make the initial hurdles to get going too high.

from community.

but what would be causes for a no?

Being in this org and thus under the Prometheus name should be an indicator of quality, and I don't think this org should be a dumping ground for any project that interacts with the Prometheus ecosystem.

So that's a question of what standards we set. For example we've elected to not list a few things on the exporter list for being unwise in the general case. I think we should have a higher bar here, and exclude
projects which have decided to not follow the exporter/client library guidelines. This is distinct from where a maintainer makes an engineering tradeoff within those guidelines.

There's also possibilities of exporters that don't work as they should, for example it's not currently possible to write a proper exporter with the Node.js client library due to technical limitations of that language/runtime/library. I think any such exporter would need to be rewritten to a different language to be accepted.

There's also the question of overlapping projects. I could imagine both Cortex and Thanos living in here, but I don't think we need N arbitrary SQL exporters or N different ways to file Jira tickets. There's already a pattern of duplicate exporters being created with no engagement with the existing exporter maintainers, and that's something I want to strongly discourage as that's not how you build a community or maintain things long term.

nomination by a maintainer ("I want this person to be able to contribute to the project I maintain")

We should probably add some guidance here, such as the 3 month rule.

if we start closed, but it becomes too much hassle to get everyone access to everything they want to work on

There's always the actual maintainer who can merge commits, so I don't see an issue here. Anyone can send a PR.
The only place I see a potential need for broader access is if e.g. there was a breaking change in a client library and someone in -team wanted to go and fix all the repos. I assume though that -team would have access anyway.

maybe if they're going unmaintained to the point of being dangerous.

I think that's too low a bar. Consider if there's a project out there not in this org that aims to replace an unmaintained one. At the point where the exporter list is updated to the new project, I think the old repo should be moved to the junkyard. Separately we would be considering getting the new project into the org.

We should also determine what we're going to do build system wise, at least for the Go projects. Do they need to re-use what we're using in the main org, or can each project do its own thing?

I think we should also be clear as to whether it's the intent that projects graduate to the main org. I say no, that a well maintained project following standards living in this org is the end goal. That's not to say that something mightn't move to the main org at some point, but I can't imagine that happening more than 1-2 times ever.

from community.

I agree that inactive projects with a viable replacement can be retired (or replaced in-place with the new code? git kinda helps here)

I agree that there needs to be some quality standard, or at least guidance within each project to what anyone can expect from it. I would not set the bar too high though, I'd rather get things into a place where they can be improved (here) than let them languish at the door until they are.

For the build system, the Prometheus one is quite elaborate for the needs of a simple Go exporter. It's there and fairly easy to copy so it can be used but I would not make that a hard requirement. The effect is mostly making "create lots of release binaries for all architectures" easy.

I also agree that this is not about graduation (thus not "incubator") but about creating a more open space for many projects to thrive in.

from community.

or replaced in-place with the new code? git kinda helps here

We can cross that bridge when we come to it.

I would not set the bar too high though

I agree, especially as we're talking about projects which inherently have tradeoffs. I don't expect projects to be perfect upon acceptance, but neither do I think we should take projects that say have decided to ignore that SD is the responsibility of Prometheus.

from community.

Regarding the projects

we can limit the initial scope for:

• exporters
• file_sd
• notifiers
• LTS

The only conditions should be:

• There is no equivalent (then a «merge» must happen)
• It is open source (with an explicit license)
• Current maintainers agree

The quality is not important (at this stage), because we want to be able to accept bad/abandonned projects to improve them. Even high quality exporters might need some tweaks.
That is why, no release should be done in the «incubation» stage.

Once quality and standadrs are reached, we do a major release wich is the starting point of the «publicity» of the project.

from community.

Regarding governance, membership

I would apply this:

https://github.com/voxpupuli/plumbing/blob/master/share/governance.md

With the only change : PMC would be 4 people elected by community (who could be from prometheus team) and 1 by prometheus team (who could not be from prometheus team).

from community.

I think it would be good to clarify both what would qualify to be hosted here, as well as why projects should want to transfer them.
For the first, assuming @matthiasr's suggestion of proposal on -developers, which sounds very reasonable, who can propose a project? Only current maintainers, or anyone? Is there an adoption criteria that projects need to meet first? It seems to me this might make sense to avoid a projects being started inside the org, and not taking off etc.

Is there a plan to offer some benefit to projects being adopted into this org? Aside from serving as a quality indicator, can we offer something else? Compute time on some cloud vendor for testing, or similar?

from community.

from community.

To answer your question more precisely, the best case is a maintainer of a project that wants to share the burden of maintaining it ; to prevent to be the bottleneck.
The best case is a maintainer who has no time to maintain an exporter anymore, then the community must stand up to support it.

from community.

Another good reason to give the exporter to the community is that in the community there is overall a good knowledge of go. You might have written an exporter for your specific thing ; you are an expert of that specific thing but not really an expert in go.

from community.

To come back to the initial topic:

https://github.com/voxpupuli/plumbing/blob/master/share/governance.md

• the rule PMC would be 4 people elected by community (who could be from prometheus team) and 1 by prometheus team (who could not be from prometheus team).

does that sound like reasonable to you? it works great for vox pupuli which is the "puppet-community" and I think it could just work fine for us.

from community.

Personally I find that the initiative is very welcomed and would be greatly beneficial the Prometheus project.

I like the idea to get inspiration from other projects like @voxpupuli that have gone this path already.

What, if any, is the level of involvement we would mandate to join this org as a member? We should strive to avoid vanity memberships to keep everything running smoothly.

I think that nominations will regulate this potential pitfall.

Does prometheus-team feel the need to retain final call in case of disagreements or should we be on completely equal footing?

Maybe have a clause stating that prometheus-team can veto eventually but I see this used as a last-resort option in case of strong disagreements.

how do projects get added to the org? (who decides what gets added)

Ask on the -dev list by the original author(s). Sponsorship by one (or more?) member(s) of @prometheus-community.
It is definitely ok that people want to maintain their projects under their own account and not join the community umbrella so we need to be careful not including a "competing" project when an established one already exists outside of @prometheus-community.

do projects ever get removed?

Seems legit when there's no active maintainer. Much harder to detect that a maintainer is not interested anymore.

does each project need some level of maintenance? do there need to be declared maintainer(s)?

Yes this should be reflected in the project itself (MAINTAINERS.md).

does maintaining / contributing to one project give push access to all projects?

It may technically if this is easier to manage but a maintainer should only maintain the project(s) she/he is responsible for.

from community.

Maybe I came across as sceptical - sorry for that, if so! I think that this is a great idea, and mainly trying to come up with questions that we should be able to answer.

This is sort of off-topic for the governance discussion, though, but maybe it would make sense to formalize the whats:

1. What type of projects are candidates to be hosted
2. What is the "offer" to these projects (such as help with automation, code review etc mentioned above)

before going into the governance, or the how of making these things happen? What do you think?
If this makes sense to others, should we open a separate issue for nailing down that and return to this one when we have a clear agreement on what the governance docs should support?

from community.