A lot of developers are joining the Morpheus community. Welcome to you all! You are a key part of the Morpheus community and there are lots of rewards to be earned for your hard work. In Morpheus 24% of all MOR emissions go to Coders and will for the next 16 years as part of all the 42 Million MOR emitted.
Tl;dr
Review Morpheus Request for Comment (MRC) list for high level understanding.
Review list of GitHub Issues for specifics.
Review Best Practices for tips on how to get your code added.
Review Code Contributor Guide to Earning Weights & Their Implied Value.
Review Reference Implementations List.
Submit a Pull Request that adds value to Morpheus.
Before contributing Code to Morpheus related GitHub repositories please read this quick guide on best practices.
Coder Best Practices
1. The Key Is To Add Value To Get Merged / Rewarded
Weights are NOT based on the Labor Theory of Value. It doesn't matter how many hours are worked but rather the value produced by the work. That's why the repository owner has to actually merge in the code (the product of the work) for it to count toward rewards. The repository owner acts as the "customer" in the marketplace. Look at other contributors to the repo and gauge the needs of the repository owner or read the current proposals in the MRC repository to see what future coding work is being proposed: https://github.com/MorpheusAIs/MRC
Please read the Code Contributor Weights Guide. to understand the implied value per weight which is updated each month.
2. Be Reasonable and Competitive
If the Code contributor is asking too many weights for the Contribution or the quality of the contribution cannot be assessed or is of low quality, it is likely to be rejected by the repository owner.
3. Combine Your Code Contribution With Request For Weights In One PR
When you do submit a pull request, consider combining the Contribution itself with the Request for Weights in one pull request, so it can be accepted or rejected by the repo owner without having to look through multiple pull requests.
4. Message The Repository Owner First
If you are considering working on something substantial that will take a lot of weights of development you should consider contacting the repo owner and inquire about their interest in the function, feature or application you are considering developing first before spending time on it.
5. Offer To Open Source Upon Acceptance
If you are concerned about contributing something closed source and it being picked up by someone else, consider starting with a more restrictive license and offer to flip it to the MIT open source standard if the Contribution is accepted by the repository owner.
6. Avoid Overlapping Commits on the Last Line of The Code - Proof_Of_Contribution.md File
When requesting weights, contributors often add their entry to the last line of the Code Contributions table. This can cause conflicts when merging pull requests as multiple requests may modify the same line.
Consider placing your commit on a line other than the last one. As Code proof moves to a monthly basis consider adding your Code to a line equal to the date of its commitment. Please use the latest snapshot table to add your contribution.
7. Timeline for Submission and Acceptance / Rejection of Code Contribution
If an idea for a future contribution is being requested, then the requester should include a timeline in the request. So for example if the GitHub repo owner wants contributors to create an Italian version of the white paper, then they should set a timeline say 7 days for submissions. Then contributors should expect that the GitHub repo owner will accept the best work done at the lowest number of weights requested.
This creates a free market for code and lets people freely compete and the GitHub repo owner gets the benefit of comparing submissions at the same time instead of just accepting whichever contributor finished first. This ought to result in better outcomes and clear expectations from both sides.
8. Review process to rate quality.
A second contributor can review other works submitted for quality and submit the review for 20% of the weights related to the submission.
9. Support / Updates To Code
If you contribute documentation, such as a translation of a white paper there is an expectation that when updates are made to the original document you will in turn update the derivitive document. If derivative contributions are not kept up they can be replaced by a different contributor and the weights credited will be re-directed to the new contributor.
10. Code & Rewards Are Dynamic
The Morpheus codebase is ever evolving. Weights credited only last as long as the codebase utilizes the code provided.
Getting started
To get started here is a short list of resources and some of the best ways to get involved and add code to improve Morpheus.
Morpheus Request For Comments:
Includes a list of all the papers / proposals related to improving, implementing Morpheus, Smart Agents, Tokenomics, & the Techno Capital Machine.
https://github.com/MorpheusAIs/MRC/blob/main/README.md
Check the list of Issue On GitHub For Details Of Ongoing Work
Includes a list of active issues reported on the Morpheus GitHub.
https://github.com/MorpheusAIs/Morpheus/issues
Best Practices for Contributing Code
The step by step details of how to Contribute Code, increase those odds of having your Pull Request merged.
Code Contributor Guide to Earning Weights & Their Implied Value
The detailed description of the implied value per weight which is updated each month.
https://github.com/MorpheusAIs/Docs/blob/main/Guides/Code%20Contributor%20Weights%20Guide.md
Reference Implementations List
Existing and new Morpheus implementations
Code Contributor Table To Include In Pull Requests
Include an update to the Code Contributor table on GitHub with your Code Contributions with your weights request.
https://github.com/MorpheusAIs/Docs/tree/main/Contributions
If a developer is looking for committees, and RFPs they are looking at the wrong project. The nature of Morpheus is Atomic Governance. That means experts build what they want and GitHub maintainers act as judges to merge if its in the platform or users decide to use the Smart Agent in an open marketplace. Coders here compete. No guarantees anyone will use the Code until its released.