Criteria for adding your name to contributors #185
Replies: 12 comments 34 replies
-
I'd say the real conflicting ones are authorship and code copyrighting |
Beta Was this translation helpful? Give feedback.
-
hi @francesco-ooops. thanks for this discussions. could you add other similar questions, to be exhaustive :
thanks ! |
Beta Was this translation helpful? Give feedback.
-
This question has been arisen because on a cherry-picking without any modification, I have asked for removing the contributor doing the cherry-picking from the README. I think that's logical, as there hasn't been any significant modification (in fact, in this case, nothing, except renaming migration folders) on the code for adapting it to the other version. I think that can be the first guideline for this: "Only add us as contributor if there are significant code changes, or review effort, including migration to newer versions. In case of cherry-picks / forward-ports / backports, only those requiring to adapt the code in a heavy way." |
Beta Was this translation helpful? Give feedback.
-
Hi. could you give exemple ? I review regularly OCA PRs, and did faced such situation. |
Beta Was this translation helpful? Give feedback.
-
On one hand, I think in an OS community anyone working on anything should receive some recognition, as even porting the smallest commit from one version to another or fixing documentation is indeed contributing to the OCA and reducing technical debt for the whole community - so adding them as CONTRIBUTORS doesn't look to me like taking anything away from more substantial contributors. If we need to address the fact that not all contributions are equal, there could easily be two sections on the file "Major contributors" and "Minor contributors" with clear rules in the docs for whether an improvement should fall in one category or the other. On the other hand, I'd like to clarify that I didn't open this poll to contest whether my (dev's) contribution should have granted CONTRIBUTORS rights, but rather to address the difficulty in welcoming new contributors to OCA when so many rules on what should and should not be done are discretionary and not written anywhere. This is a hurdle for scaling, it's wasting everyone's time and it definitely does not help the experience of publishing code in OCA. I hope this can be taken in consideration and realize that even an imperfect guideline at times is better than no guideline at all. |
Beta Was this translation helpful? Give feedback.
-
Leaving this link here as food for thought https://allcontributors.org/ (I haven't personally tried the tool, but I like the approach at least) The discussion so far is very interesting, but it's focused almost exclusively on technical contributions. I think writing documentation can still be extremely valuable and should be encouraged and recognized as meaningful contribution. |
Beta Was this translation helpful? Give feedback.
-
I agree a guideline is needed. IMHO we should stop thinking about what is a "meaningful contribution" and start thinking of "helpful contributions". In our context, we could define "helpful contribution" as anything that makes something better than it was before, or helps others doing so. That is a simple guideline that lifts everyone from the heavy burden of judging others or being judged by others. It can apply to many actions apart from code, and I think that is a good thing. |
Beta Was this translation helpful? Give feedback.
-
I agree that
(from https://github.com/orgs/OCA/discussions/185#discussioncomment-10657119) so the author deserves a spot in CONTRIBUTORS. In order to show how much a contributor has done, CONTRIBUTORS is not the right place in my opinion because it implies someone deciding whether the contribution is worth of going there, so it becomes subjective. TL;DR: CONTRIBUTORS is just a list of anyone who contributed, how much can be retrieved from GitHub statistics. P.S. Can someone vote in the poll? |
Beta Was this translation helpful? Give feedback.
-
I'd like to point out that the "contribution" is not limited to the individual who writes the code. I think the PM/PO/analyst/functional who identifies a bug/improvement and often designs the solution to be implemented is contributing to the module and the community. |
Beta Was this translation helpful? Give feedback.
-
Copyright issues are primarily governed by law, with ownership typically assigned to the client funding the work, or the entity bearing the costs. The OCA’s role is to manage what appears under authors and contributors, but copyright laws remain beyond the community’s control. When considering contributor recognition, it's crucial to remember that much of what’s discussed here is subjective opinion, not universal fact. Often, rare cases—representing only 5% of situations—become the primary focus of debate, diverting attention from broader challenges. Discussions around fairness often lead to dead ends, as what feels fair or unfair is subjective. Instead, we should focus on learning from larger open-source communities and applying those lessons. The OCA is relatively small, and the real objective should be organic growth, not individual accolades. Although functional reviewers haven’t been recognized, the deeper issue lies in a lack of community expansion. The OCA hasn’t seen growth in contributors for years, and contributors have left for other projects. In light of this, debating contributor recognition seems shortsighted. The more important question is: how do we build a community that fosters long-term, sustainable participation? In a space where contributions are often motivated by financial rewards or recognition, fostering a culture of humility and collaboration is vital. We need to create an environment that motivates participation and attracts new contributors—focusing less on personal gain and more on the collective good.
When doing so results in growing the number of contributors, so we can count them in the thousands, not just the hundreds. |
Beta Was this translation helpful? Give feedback.
-
IMO The real point is: what do we value?
@pedrobaeza once upon a time you told me that even for a migration where you changed nothing (just the major version number) you should be listed into contributors. Motivation: very likely you analyzed the code, tested on a new version, etc. On this particular case, cherry-picking commits, I see the same value. Why? Because when you cherry-pick a fix or an improvement your doing someone else's job: checking the code, adapt it if needed (eg: conflicts), test it on the new/old version, etc, and very likely you tested it on your customer project. As an author this saves me time. As a maintainer, this saves me time. As users of this huge bucket of code, we all save time. As @SirAionTech pointed out
Now we might argue that some contributions shouldn't be "mixed up" with maintainers work or long time contributors, bla bla. So the main question here is: how can we make everybody feel accepted and recognized? I've recently stumbled upon the requests lib repo where do this on the authors file: and they also give recognition to new contributors on the release notes I think we should tend to something like that. From my POV it gives more recognition to authors and maintainers while still giving recognition to smaller or random contributions. My $0.02 |
Beta Was this translation helpful? Give feedback.
-
I have been reading all the opinions and I would like to contribute with my point of view to this debate. Far from being presumptuous, what I’d like to say is that with perseverance, effort, dedication, and the investment of resources and time, results eventually come in the form of the “right to subjectively decide” what is correct and what is not, in the repositories where we are PSC. To summarize:
I believe regular contributors have earned this "right to decide", and it’s been through:
Everything can be debated, but realistically, 90% of the OCA is being maintained and improved by a very small number of partners, not by a large number of occasional/new contributors. It is on the major contributors (and many of us are also Sponsors) where we should focus. We don’t need to cater to the occasional contributor (who also will never be a Sponsor) instead of keeping the regular contributors motivated. If another PSC thinks adding me (or my team) as a contributor is too much (it has happened to us, as well), what’s wrong with that? They’re not telling me this to “annoy” me, but because in their judgment (in a repository they primarily maintain for free) they believe it’s not the most appropriate. I don’t think it’s wrong for someone who has dedicated (and continues to dedicate) so much effort, to have more "power" than the occasional contributors and to be able to decide according to their own criteria, as long as there are valid reasons. What I would do:
My two cents. |
Beta Was this translation helpful? Give feedback.
-
Hi,
to try as much as possible to stay clear of grey areas, here's a question for the community (with the end goal of clarifying guidelines):
17 votes ·
Beta Was this translation helpful? Give feedback.
All reactions