search

MerosCrypto / Meros

An instant and feeless cryptocurrency for the future, secured by the Merit Caching Consensus Mechanism.
https://meroscrypto.io
Other
83 stars 19 forks source link

Guidelines for contributing. #281

Open bitcoinsfacil opened 3 years ago

bitcoinsfacil commented 3 years ago

"Having firm guidelines on project management and getting involved is extremely valuable" @kayabaNerve

https://github.com/MerosCrypto/Meros#contributing this is not enough, will research on some good ones.

kayabaNerve commented 3 years ago

Since we're discussing GH contributions, there's two factors to consider.

1) Issues. 2) Development.

For the former, we should use issue templates. We also need to make sure to include a note to not close any issue UNLESS it's a bug report that the user figured out was user error. Any feature request, even if the original user no longer wants it, should only be closed by maintainers so they can review if it has benefit to the wider space (especially once other people start participating on the issue). If it's a bug, with a user workaround, then it needs to only be closed when fixed.

For the latter, we have that open welcome, which also says to look at our open issues for WHAT to do, yet we also have https://github.com/MerosCrypto/Meros/tree/master/docs/Development. That details how to set up Meros itself and how to style contributed code. That said, the docs are a bit scattered.

Any networking/flow changes need to be checked against the Python test suite, which has its own setup guide (https://github.com/MerosCrypto/Meros/blob/master/e2e/README.md). Any Python changes also need to be checked against pyright/mypy/pylint. That document details how to setup/check against pyright/mypy/pylint, yet doesn't mark it as a firm requirement for contributions.

We can improve the CI to run those three tools, so there's automatic notification if a user forgets to and contributes an error.

bitcoinsfacil commented 3 years ago

Ok on everything. I like some parts of this article taken from Monero contribuiting file.

On-boarding people, devs or not, is the final goal.

kayabaNerve commented 3 years ago

The first article is great, as is Monero's commentary on hosting and editing source code (patch requirements).

I do want to note we aren't compatible with C4 specifically for its requirement of a share-alike license. As for copyright ownership, that will be changed before launch so we're currently incompatible, but won't be. I do get you weren't suggesting we adopt C4, just pointing that out. I also don't personally agree with its verbosity and some rules about the development process

kayabaNerve commented 3 years ago

We also need a document on responsible disclosure.