request for comments on contributing standards and acceptance criteria

[pakaplace]

As the pull requests pile up, and as contributors may have motives that stray from the purpose of helping other developers (promotion, spam, etc.), I wanted to start a conversation on what the criteria should be for accepting new contributions.

To start it off, here are some things I thought of:

• What falls under the scope of developer tools? If it's outside (e.g. DApps) should we include a separate heading for well-built DApps that aid people's understanding of them
• Should proposed tools have met a certain threshold of usage? Could this be captured in a number of Github stars or forks?
• Should repo maintainers be required to use and evaluate the tools before adding/removing from the list?
• What reasons/feedback should be provided by maintainers if a proposed tool is rejected?

These are the opinions of myself, not ConsenSys. Check out the commit for a rough outline.

[corbinpage]

Great questions @pakaplace. I think we should start being more strict about including only libraries and tools that help the average developer get started building within the Ethereum and decentralized ecosystem. And remove things like Block explorers, some of the Services, Knowledge, References, Governance, Decentralized exchanges, list, etc. Or maybe add them to the wiki or a separate README instead of the main README.

I think we should prioritize smart contract development (especially the best-in-class referenceable contracts) and the useful web tools for quickly creating a dapp. Given the sheer number of tools (and growing), we should also call out the best-in-class, most widely adopted tools to make it easier for a new developer to navigate, while still including the full list of a complete reference.

[mkosowsk]

@pakaplace thinking about standards and acceptance criteria are absolutely necessary as this project continues to gain traction :)

What falls under the scope of developer tools? If it's outside (e.g. DApps) should we include a separate heading for well-built DApps that aid people's understanding of them

This makes sense to me, +1

Should proposed tools have met a certain threshold of usage? Could this be captured in a number of Github stars or forks?

I would argue yes, 100 stars or something like that is a good way to separate more hobbyist projects from things that people actually use.

Should repo maintainers be required to use and evaluate the tools before adding/removing from the list?

In a perfect world, yes but only so much time in the day :) best to lean on the community to vet projects.

What reasons/feedback should be provided by maintainers if a proposed tool is rejected?

I think this should be very clear and most likely tied to some usage statistics.

per @corbinpage I agree strongly with this comment:

I think we should prioritize smart contract development (especially the best-in-class referenceable contracts) and the useful web tools for quickly creating a dapp. Given the sheer number of tools (and growing), we should also call out the best-in-class, most widely adopted tools to make it easier for a new developer to navigate, while still including the full list of a complete reference.

As an aside, I think this Ethereum Developer Tools List would be an excellent candidate for an eventual token-curated registry (TCR).

I will be following this repo with great interest, think I may try to do something similar with the Ethereum Roadmap a la https://ethereum-magicians.org/t/ethereum-roadmap/746 (this also may make sense as a TCR).

Great work, @pakaplace! 수고헸어 ^^

[greggirwin]

+1 for requiring working code, not just an idea.

Could entries be ordered by stars, maybe including a staff pick badge the repo maintainers can apply?

[crazyrabbitLTC]

Hello! This is Dennison Bertram, Developer Advocate at Zeppelin.
I wanted to ask if we could add ZeppelinOS to the developer tool list. With ZeppelinOS you can create upgradable smart contracts, create and link EVM packages, and do all of your Smart Contract Development. It is a complete development environment for smart-contract developers.

[pakaplace]

Hi @crazyrabbitLTC , others have already added ZeppelinOS (in multiple places actually). If you'd like to update the description, please feel free to do by opening a PR.

[pi0neerpat]

Closing for now. Please re-open if you wish to continue