Suggestion: Publish a detailed technical development division of labor list to help development contributors quickly understand the project and participate in its development. #356
Replies: 2 comments 4 replies
-
|
Thanks for posting this, @JackLamCHN! I strongly agree we need more documentation on how to use Commonware (i.e. tutorials/walkthroughs). I expect we'll spend some time on that after our current sprint (if someone doesn't beat us to it: #230). I also strongly agree making the development roadmap public is a good idea for others to "see how it all comes together". I haven't had time to type this out yet but do plan to (in the meantime, the issues are a good place to look for work). As for "Token Rewards"/"Incentive Mechanisms" for contribution, we aren't planning to go down this route. Folks should contribute here because they find the code useful and/or the mission compelling (like they would contribute to Linux). There should be no expectation of "payment". If external projects/companies want to sponsor a particular feature (that would benefit them), we are happy to collaborate with engineers on how they should design/approach getting such a feature merged. |
Beta Was this translation helpful? Give feedback.
-
|
Yes, I had two programmers from my team look at Commonware's codebase, and this is their suggestion: detailed technical documentation will more effectively enhance programmers' understanding of Commonware. If you need to produce instructional videos, feel free to contact me; I can organize professional English voice-over artists and video editors for the production. These are some tutorials and introductory videos that I made previously.
A roadmap can visually illustrate the project's progress and future plans to both programmers and non-technical staff. Sharing an image-based roadmap on social platforms can also serve as excellent marketing. If you need design support, please let me know. Hahaha, I see, you're aiming to attract tech developers through recognition, practical value, and a sense of honor. That's really cool.👍 |
Beta Was this translation helpful? Give feedback.
-
|
Just to chime in here for documentation. Can I suggest using Quarto If @patrick-ogrady wanted to create a repository for docs I'm more than happy laying out a general outline and starting to get this up and running. |
Beta Was this translation helpful? Give feedback.
-
|
I've used Docusaurus before and that was reasonable but haven't done much outside of it. I've also heard you can write pretty nice books using Rust docs and have been tempted with that. In an ideal world, we find a way to keep everything in the monorepo to avoid sprawl (unless there is good reason not to). |
Beta Was this translation helpful? Give feedback.
-
|
The cool thing about Quarto is you can embed code. So often the hardest part is to simplify these concepts into language and representations as simple as possible. I've found that Quarto is cool as it has native support for Mermaid as well as embedding Python code. So if you wanted to show something like a benchmark test or how Simplex consensus works, you could mock up an animation in Python and then when the Quarto site deploys, the output will be embedded in the pages. I've used it for an Almanack I've worked on https://hariseldon23.github.io/degen-almanack/content/financial/dexes.html and the ease of use is fantastic. The cool thing about Rust docs is you can export to epub. This is also a native feature in Quarto. I find this really helpful when I want to read on my Kindle when I'm travelling. An argument could be made that documentation should live outside the monorepo if the docs become more of a living site versus pure documentation. My personal thoughts are that blockchain technology needs a lot of visual representations to really grok the subject matter. That's why Mermaid charts, Manim animations and Quarto Dashboards really allows a documentation site to become much more beneficial to newcomers. If you look at the Cosmos SDK document you can see Mermaid style charts littered throughout. Then there is also version control to take into account. If the storage Journal in future version implements QMDB 🫰 then you'd need the documentation site to handle versioning. Rust docs handles that, but even in these immediate concerns I believe the documentation site will quickly run into issues being within the monorepo.
Looking at that table, perhaps Docusaurous makes the most sense for strong versioning, but if you want good mathematical notation then Quarto starts to shine. |
Beta Was this translation helpful? Give feedback.
-
I suggest that all of our open-source documentation be released in a state that is "code-able," "highly compatible," and "easily migrable." This is because in the technology sector, excellent product iterations happen very quickly, and new products are continuously being launched. Not just us, but all blockchain projects that have grown to a certain scale face issues with presenting and migrating documentation. Products are becoming more user-friendly, but the migration of complex legacy documentation is becoming increasingly difficult. The advantages of being "code-able," "highly compatible," and "easily migrable" can ensure our documentation always offers a good reading experience. Moreover, if an outstanding content product emerges in the industry, like the aforementioned Quarto, we can immediately adapt to it, syncing over with the lowest migration cost to optimize work efficiency. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
To help тех enthusiasts new to the Commonware project quickly grasp the project details, we should consider creating a "mind map" or a table that outlines the web development roles. Based on this, we could also introduce corresponding token reward details and referral incentives.
Details:
1、Share Project Information through "Mind Map" or Checklist:
Share key aspects of the project like functional modules, specific development tasks, assigned volunteers, development timeline, and progress using a mind map or table format.
2、Clarify Developer Responsibilities:
For tasks already assigned, clearly indicate the responsible developer. For tasks that need volunteers, list the technical requirements or skills needed for developers to take on those tasks.
3、Timeline and Progress:
Define the time and progress needed for each development task. This overall table can be used to issue technical and progress reports.
4、Token Rewards Based on Task Complexity:
Once tasks are detailed, determine token rewards based on the complexity, duration, and hours required for each task. Clear token incentives will attract more developers.
5、Invitation Incentive Mechanism:
If rewards for tasks are set, introduce an invitation incentive system. Most users in the blockchain world are not developers but form a vast social network. If a user invites a developer using their unique invitation code or link, and that developer contributes to and completes a task whose code is successfully merged, the inviting user can receive a percentage of "referral bonus tokens" in addition to the developer's reward.
Overview:
By implementing a public, transparent, and detailed project development schedule, we can save developers time in understanding the project, allowing everyone to see the project's structure and progress at a glance. Those with technical skills can volunteer to contribute directly to the project and earn token rewards. Meanwhile, non-technical individuals can utilize their social networks to invite tech-savvy participants, leading to a win-win situation.
This is my personal suggestion, and I hope the team will consider and adopt it. Thank you for your attention.
Beta Was this translation helpful? Give feedback.
All reactions