Create project acceptance document #9
Comments
|
Potential criteria I've seen mentioned already, or could come up:
|
|
we should welcome any prometheus related prolect in any state as long as maintainers are willing to and there is no other similar project in the org |
These sound sane.
There needs to be a vetting mechanism of some sort, sponsoring for maintainers comes to mind, to prevent people from "starting" vanity projects and then not working on them. Again, end users will expect a certain baseline of functionality and/or improvement over time. |
|
I like the idea that a project needs to be sponsored by the maintainers of the community. I don't think that there's need to be a majority of maintainers actively sponsoring but probably at least 2. |
|
Yah, my thinking is to have 2-3 sponsors from the community; initially, this would need to be prometheus-team by defintion, but as prometheus-community gains more maintainers, it would make sense to give them the same sponsoring ability. |
|
Maybe there should be separate criteria for the two different cases I can see happen:
Case 2 would require a higher commitment, so perhaps different considerations. I'm by the way assuming here that there will be some form of "primary maintainers" for each repo, rather than a large group of people who are maintainers for all of them? |
|
https://github.com/cloudflare/unsee a project that is abandonned but useful ... a good example of what I would expect in prometheus-community |
|
Would you expect to move it without active maintainers or are you proposing
to take it over yourself? Did you talk to the old maintainers about this?
Sent by mobile; please excuse my brevity.
…On Wed, Aug 29, 2018, 20:14 Julien Pivotto ***@***.***> wrote:
https://github.com/cloudflare/unsee
a project that is abandonned but useful ... a good example of what I would
expect in prometheus-community
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/prometheus-community/prometheus-community/issues/3#issuecomment-417052088>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAuEI5sE7UdpvanIJeuqDgFsWFUUaLREks5uVtoMgaJpZM4WRE96>
.
|
|
I would expect that as a user I would propose them to move it to this org ; not maintaining it ; but if it is here then the community can take over the maintenance. It means: reviewing and accepting PR mainly. |
|
cloudflare/unsee#267 (comment) is the comment stating that it is no longer maintained |
|
And I do not think that we need to sponsor the projects. They can just come in without maintainers, then all contributors of prometheus-community can act on it. |
|
Assuming we move this over, users start to rely on it, and it breaks, what
mechanism do you expect to ensure that bugs will be fixed or features
updated?
Sent by mobile; please excuse my brevity.
…On Wed, Aug 29, 2018, 20:40 Julien Pivotto ***@***.***> wrote:
I would expect that as a user I would propose them to move it to this org
; not maintaining it ; but if it is here then the community can take over
the maintenance. It means: reviewing and accepting PR mainly.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<https://github.com/prometheus-community/prometheus-community/issues/3#issuecomment-417061135>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAuEIywPrgQanRlz4fNoOh0KlzAkfz6Lks5uVuAUgaJpZM4WRE96>
.
|
|
pull requests :) |
|
that is the difference between your vision and mine: I would welcome any project and let anyone improve them. And you want to have a list of "semi official" projects with high quality from the start :) which makes sense if you call it "prometheus" :) |
|
Right, so that is a fundamental difference of goals which needs to be resolved for the discussions to make sense. I guess I'm on the "quality gated" side. I see a big risk that we'd end up with just moving dead projects into the organisation, and then having user expecations of fixing things. I would then expect the "community maintainers" to feel they have a pretty thankless and burdensome task, and would drop off. |
|
To address this it is important to have a clear and out-of-the-way governance, and many many many contributors with push/merge rights. People should not have any other expectation that the expectation that someone in the community can merge their pull requests. I expect most of the projects lots of people will use will remain active and for the projects that are really dead, we could "github archive" them. Which would mean that we can unarchive them at any moment when someone feels lke fixing that. But that archive process should be the exception. |
|
The situation is worse with sponsoring. When you sponsor or say that you will maintain a project, that is where the burden begins. Letting the projects come in without designated maintainers (maintainers are everyone in the org) let the people a lot more free to leave at anytime. I have maintained for years some puppet modules. |
|
Sidenote: I think we'd be more able to reach some sort of consensus around this if we try to see different aspects of it, rather than repeating a previous viewpoint and/or presenting opinions as facts. I agree the data point about the similar Puppet group is interesting. What I worry about in the comparison is that the typical user is quite different for Puppet vs Prometheus. Puppet users are by definition able to contribute to Puppet modules. Prometheus users, however, are in my experience not primarily developers, much less Go developers. Perhaps we have some data on this from some survey, @RichiH?. If so, there is a much smaller population to draw maintainers from. Are there enough? This probably also colours my view on user expectations. In my experience, maintaining half a dozen or so exporters, most of the users are willing to file issues or feature requests, but most are unable or unwilling to contribute with implementation. |
The last survey was 3 years ago, and doesn't help answer this question. I meant to do another one last year, but got side-tracked.
My feeling is that the pool of potential maintainers is very small for a given exporter. You need someone who is familiar enough with the Prometheus data model/exporter guidelines, a relevant programming language (probably Go), and has sufficient knowledge of the relevant system to understand it and what its metrics mean. Personally this usually ends up with me reading the source code of applications to figure out what their metrics mean from basic semantic questions, to units, to counter/gauge. This often includes the ability to determine from the source code the full semantics of a bespoke instrumentation library. In practice this means that for every single exporter, getting up to speed on how the relevant exportee/exporter works for a typical developer could take a few hours. And that's per exporter. On the plus side the actual coding work of writing/maintaining an exporter is usually pretty light, the only time it tends to be complicated is when it has been over engineered. There are exceptions like SNMP, but those are rare. Overall I can't see one person maintaining more than 3-4 exporters, there's just too much domain knowledge to keep in your head. Plus day-to-day maintenance stuff like keeping up with issues/PRs, and having enough context to determine if a feature request was sane. As a data point in the Prometheus org 2-3 exporters per maintainer is typical, and we don't see maintainers frequently jumping between or working across exporters.
This is also my experience, it's a standard thing in open source. |
|
I think the framing of @carlpett 's question is very important, but slightly off. No one is disputing that everyone can, and should, improve a project; I see the dividing question as "do we need a failsafe mechanism, with specific personal responsibilities, to ensure a baseline of maintenance and quality?" - would you agree @roidelapluie ? In my experience, personal responsibilities are the only thing that work. Even in Debian, CCC, and other more equal organizations, we assign specific roles for specific tasks. |
|
Yes I agree -- but at some points you want to improve something and the maintainer is gone -- if the project is in prometheus community, then we can have a new maintainer. if the project is somewhere else, we are possibly blocked and a new fork needs to be done, then someone else will do another fork, and a third one... so I'd still get as much projects as possible under the community umbrella |
I am unsure if we are talking about the same thing. Do you or do you not think a project could be moved into prometheus-community without having at least one specific person take responsibility for said project? |
|
I do think so because then later on someone can be appointed maintainer. If we do not take the project then we need to work with the previous maintainer later to change ownership; which might not be a good time for them anymore. |
|
OK, thanks for the clarification. I disagree with this as I don't anticipate that this model will work well and has the potential to make users assume we would be taking care of things when, factually, we would not be. |
|
So, we are sort of at an impasse here? How do we move forward? |
|
On 25 Sep 10:01, Calle Pettersson wrote:
So, we are sort of at an impasse here? How do we move forward?
There is no impasse, just two ways of seeing things. I propose to follow
Richie's lead for this project.
|
|
Sorry, maybe my language was off - what I meant was just what you are saying. Two different viewpoints, that cannot easily be reconciled, so there needs to be a choice to go either way. @RichiH Input from your side? Do we have sufficient ideas for the document in the early parts of this thread, or should we resume that bit? |
What projects do we want to accept? Do we want to exclude anything?
The text was updated successfully, but these errors were encountered: