chore: add contributors

[achrinza]

This is a draft PR to demonstrate a POC on using the all-contributors spec.

fixes #981

Signed-off-by: Rifa Achrinza [email protected]

Checklist

👉 Read and sign the CLA (Contributor License Agreement) 👈

• npm test passes on your machine
• New tests added or existing tests modified to cover all changes
• Code conforms with the style guide
• API Documentation in code was updated
• Documentation in /docs/site was updated
• Affected artifact templates in packages/cli were updated
• Affected example projects in examples/* were updated

👉 Check out how to submit a PR 👈

[dhmlau]

@achrinza, i'm not familiar with all-contributors. Are the changes in this PR generated?
If so, does it get run periodically automatically? Thanks.

[achrinza]

@dhmlau There's a CLI that checks for contributors that haven't been added yet. I took the output of that and ran the "all-contributors add" command for all those contributors (excluding project architects, maintainers and bots).

Right now it's somewhat manual-ish. But it should be possible to automate this with a JS script.

I'm not sure if Travis-CI can run cron-like jobs.

[raymondfeng]

@achrinza Do you want to add https://allcontributors.org/docs/en/cli/installation#5-optionally-add-shortcut-scripts-to-your-packagejson?

[achrinza]

@raymondfeng Good idea, I've added it in.

[achrinza]

I noticed that the code generated by all-contributors generate doesn't play well with Prettier (The extra newline on L188 is not there when generated). So I've added an extra step to the npm script to run Prettier against README.md.

I'm not sure if this is a good way to do it.. I'm open to suggestions.

[bajtos]

Thank you @achrinza for this proposal.

I don't have a strong opinion on this topic. Personally, I don't mind the current README, but I also like the newly proposed one.

I guess my only concern is that we will have to remember to periodically run the new npm script and commit the changes.

For longer term (but out of scope of this pull request), it would be great to find a way how to automate these updates. Perhaps via GitHub Actions?

I also found https://github.com/all-contributors/all-contributors-bot, but I am not sure if that will automatically add new contributors when their first PR is landed.

[achrinza]

For longer term (but out of scope of this pull request), it would be great to find a way how to automate these updates. Perhaps via GitHub Actions?

I think that's a great idea; it can be a stepping-stone to testing out GitHub actions for issues such as #3161.

I also found https://github.com/all-contributors/all-contributors-bot, but I am not sure if that will automatically add new contributors when their first PR is landed.

AFAIK it's not automated; the bot will still need to be called via a PR comment.

[dhmlau]

+1 for adding the contributor list section. Thanks @achrinza for looking into this.

It would be good to looking at GitHub Actions for updating the contributor list automatically soon, even if it's not a pre-requisite for landing the PR.

[emonddr]

@dhmlau There's a CLI that checks for contributors that haven't been added yet. I took the output of that and ran the "all-contributors add" command for all those contributors (excluding project architects, maintainers and bots).

Right now it's somewhat manual-ish. But it should be possible to automate this with a JS script.

I'm not sure if Travis-CI can run cron-like jobs.

https://docs.travis-ci.com/user/cron-jobs/

[dhmlau]

@emonddr, we can run cron jobs on travis. In loopback.io, we ran some cron job daily as well. But i'm not sure where to specify which scripts to run in that cron job. If you can find out, I can change it too (if you don't have the rights on Travis to do that).

[raymondfeng]

Travis cron jobs can be set at https://travis-ci.com/github/strongloop/loopback-next/settings

[dhmlau]

@raymondfeng, do you know how to specify what scripts to run?
For example in https://travis-ci.com/github/strongloop/loopback.io/settings, I can see how frequent the cron job runs only.

[raymondfeng]

It probably runs what's defined in .travis.yaml. Maybe we need to have it configured for loopback-governance?

The other option is to have a task based on the following env var:

Detecting Builds Triggered by Cron #
To check whether a build was triggered by cron, examine the TRAVIS_EVENT_TYPE environment variable to see if it has the value cron.

[rmg]

I think it might be easier to do this with GitHub Actions than with Travis. You could use something like Update File on GitHub to update the file directly or Create or Update Pull Request to submit the change as a pull request for review. Either action could be configured to be triggered by pushing or on a cron schedule.

[bajtos]

LGTM as the first step in a possible longer journey 👍

@achrinza can you please resolve the merge conflicts in package & package-lock files? It may be easiest to revert the changes in those two files, run git rebase master and then npm install. Just an idea 🤷‍♂️

Lets allow few more days for @dhmlau @raymondfeng @emonddr to raise any objections they may have. If there are none, then I think we can proceed to land this PR 👍

BTW I think it would be great to some docs for updating the list of maintainers, perhaps to docs/MAINTAINING.md? Describe the npm scripts that are available, show examples on how to record non-code contributions, etc. This can be done in a follow-up pull request if you prefer.

[dhmlau]

+1 to land this PR and have follow up task on automating this problem and documenting it. Thanks @achrinza.

[bajtos]

I believe our master branch is protected and may not allow direct pushes. I think it's better to open a pull request even for these semi-automated changes. Not only it give us a chance to run CI and review the changes, it will also trigger a notification to people watching the project. (Commits don't notify.)

[achrinza]

@bajtos @raymondfeng The instructions were assuming that the readers just opened a PR, and that the workflow would be:

1. User opens a PR for a fix/feat/chore/etc.
2. User runs contributors:add which adds another commit
3. User pushes the new commit
4. PR gets merged, with both the original and the attribution commit.

The idea was to minimize the number of PRs and the amount of effort. It also assums that the user would've checked out a new branch if the PR was only to add attribution, as we already have a detailed page on how to contribute to LoopBack 4 which documents this process.

If we split it into 2 separate PRs, the workflow would become:

1. User opens a PR for a fix/feat/chore/etc. (original PR)
2. Original PR gets merged
3. User checks out a new branch for adding attribution
4. User runs contributors:add which creates a new commit
5. User pushes the new commit and branch
6. User creates PR (attribution PR)
7. Attribution PR gets merged

WDYT?

[bajtos]

The instructions in this section don't mention pull requests at all, that's why I assumed the intention is to commit directly to master.

1. Add an attribution
2. Push the changes.

Can you please add more content to this section and clarify that we expect a feature branch & a pull request to be used? I think we don't need to duplicate instructions for working with feature branches and pull requests (we already have docs for that elsewhere), just mention it in the list of steps.

I am not sure if it's a good idea to ask contributors to add themselves to the list as part of their pull request contributing a feature. It adds noise to pull requests and increases chances of merge conflicts. I think it's better to update contributors on a semi-regular basis using a short-lived pull request (i.e. create a new branch, update contributors, open a new PR, wait for CI to finish, merge the PR without waiting for review).

Maybe we can support both options and explain in the documentation why/when to use which one?

[raymondfeng]

@achrinza Would it be even better to automatically update .all-contributorsrc using simple apis?

• https://api.github.com/repos/strongloop/loopback-next/contributors
• https://api.github.com/users/

[achrinza]

@raymondfeng Sounds like a good idea. I'm still working out what's the best way to go about it.

The all-contributors CLI has a Node.js API, but it's experimental. Nonetheless, I'm trying to see how we can utilize the CLI where practical.

[dhmlau]

We just switch the contribution method from CLA to DCO, making your contribution easier in the future. Please sign the commits with DCO by amending your commit messages with -s flag and push the changes again. If you're using the command line, you can:

git commit --amend -s
git push --force-with-lease

Please refer to this docs page for details. Thanks!

[stale]

This pull request has been marked stale because it has not seen activity within two months. It will be closed within 14 days of being stale unless there is new activity.

[stale]

This pull request has been closed due to continued inactivity. If you are interested in finishing the proposed changes, then feel free to re-open this pull request or open a new one.