How to be a LB maintainer

[dhmlau]

As suggested by @bajtos in here, when our community (especially LB4 community) grows, we need to grow the number of maintainers to make our project sustainable.

This topic started a while back mid last year, and I think we should continue the discussion here. Trying to summarize what we left off.

• Criteria#1: Agree with our principles (http://loopback.io/contributing/)
• Criteria#2: Ability to demonstrate some understanding of how LoopBack works
  How?
  - At least have 1 meaningful pull requests being merged
  • Concerns: Other than code, help triaging, helping people to explain things and expressing opinions in technical discussion show this ability. What would be the quantifiable way?
• Criteria#3: Demonstrate the ability to express effectively in written form on technical discussion
  How?
  • Involve in discussion at least 1 Github issue on proposed solution/comment on PR from others

cc @raymondfeng @bajtos @kjdelisle

[kjdelisle]

I'm not sure about Criteria #2; we're still inventing the framework. There's only so much I would expect someone to understand, especially given that the framework is still in a state of flux that often leaves us individually needing to catch up now and then!

I think competent contributions in the form of pull requests or good review comments will quickly demonstrate a community member's skills, and if they are frequent enough, that's a good sign that they're interested in helping build LoopBack 4.

[dhmlau]

I think competent contributions in the form of pull requests or good review comments will quickly demonstrate a community member's skills

I think if someone has a good PR or review comments, doesn't it already show that he/she has some understanding of LB and therefore Criteria#2 is met?

Even this issue is created in the LB4 repo, I'd like to extend the criteria to all LB repos.

[dhmlau]

@raymondfeng @bajtos, any thoughts?

[bajtos]

I am personally fine to keep the criteria vague. For example, the Node.js project don't have any hard criteria either AFAICT.

https://github.com/nodejs/node/blob/master/GOVERNANCE.md#collaborator-nominations

Any existing Collaborator can nominate an individual making significant and valuable contributions across the Node.js organization to become a new Collaborator.

nodejs/node#18090 (comment)

I also think we should avoid putting up a list of 'hard' requirements as some contributors ramp up quickly, while others contribute more consistently but over a long period of time so its hard to come up with a one size fits all.

nodejs/node#18090 (comment)

For my part, I do hope one day I'll be fit for collaboration, but I know I'll be far from the level some here have. Putting hard requirements would pretty much crush that hope for me, and for many IMHO.

https://medium.com/the-node-js-collection/healthy-open-source-967fa8be7951#13a3

All contributors who land a non-trivial contribution should be on-boarded in a timely manner, and added as a committer, and be given write access to the repository.

---

I think this discussion format is not working very well, at least not for me. Would you @dhmlau mind opening a pull request showing the specific changes you would like to make in our contributing/governance documentation?

BTW I quite like these two documents from Node.js project: GOVERNANCE.md and COLLABORATOR_GUIDE.md, it would be great to eventually cover similar topics in our LB documentation too.

[virkt25]

+1 to have a Governance and Contributing .md files in the repo. I personally think that's better than putting it in LB Documentation (it can be replicated there but the repo should contain everything needed to get started). Most other Open Source project I've seen follow the same process.

---

On an unrelated note, I think it might be helpful to create a CONTRIBUTORS.md file to recognize everyone who contributes to the project (ideally it'd be a part of README.md but I think it might grow too big ... on that in a minute). I came across this tool used by carbon-design-system that aims to recognize all contributions (big and small ... not just via code) and the tool does most of the work for us. I think it's a great way to show our appreciation to the community.

The tool: https://github.com/kentcdodds/all-contributors
Carbon Design System: https://github.com/carbon-design-system/carbon-components

Contributing Guide for Carbon (I like the simplicity and step-by-step instructions for everything!): https://github.com/carbon-design-system/carbon-components/blob/master/docs/contributing.md

[bajtos]

+1 to have a Governance and Contributing .md files in the repo. I personally think that's better than putting it in LB Documentation (it can be replicated there but the repo should contain everything needed to get started). Most other Open Source project I've seen follow the same process.

The downside of this approach is that whenever we want to make a change in Governance or Contributing file, we need to replicate those changes to very LoopBack repository. In LoopBack 3.x, that meant 90+ git commits to make IIRC. Now that we have a monorepo for LoopBack 4+, there are less repositories to maintain, but we are still not down to a single repository.

Could we perhaps keep per-repository Governance and Contributing files short and pointing to the shared contents on loopback.io website?

On an unrelated note, I think it might be helpful to create a CONTRIBUTORS.md file to recognize everyone who contributes to the project (ideally it'd be a part of README.md but I think it might grow too big ... on that in a minute). I came across this tool used by carbon-design-system that aims to recognize all contributions (big and small ... not just via code) and the tool does most of the work for us. I think it's a great way to show our appreciation to the community.

+1 ✖️ 💯 for recognizing all kinds of contributors, not only people contributing code changes.

@virkt25 could you please open a new issue where we can discuss this idea? Let's keep the discussion here focused on the topic of "How to be a LB maintainer".

[stale]

This issue has been marked stale because it has not seen activity within six months. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository. This issue will be closed within 30 days of being stale.

[stale]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.