This proposal establishes a fair compensation structure for contributors to the Layer 1 code of the Luna Classic blockchain. The goal is to incentivize developers while ensuring decentralized governance, transparency, and accountability.
Compensation Structure
Code Review Compensation
Amount: $900 USD / $794.02 EUR
Description: Contributors who submit pull requests for Layer 1 code will receive compensation for the code review process to ensure quality and reliability.
Code Merge Compensation
Amount: $400 USD / $352.90 EUR
Description: Contributors whose code is successfully merged into the main branch will receive this compensation as a reward for their integration efforts.
Contributor Reimbursement
Reimbursement for Governance Proposal Expenses: Any expenses incurred with the creation of governance proposals seeking funding will also be reimbursed. Contributors should document their expenses and include them in the proposal submitted for community voting.
Governance and Funding Mechanism
Decentralized Funding
Utilize funds exclusively from the Community Pool, disbursing them directly to contributors’ wallet addresses through governance spending proposals that receive approval from the community.
Payments will be issued only after the work has been satisfactorily completed and the spending proposal has been approved through governance.
Community Governance
All compensation proposals must be submitted by the Layer 1 contributors themselves and will go through a community voting process. This ensures that the community has a voice in approving compensation requests.
Our current governance framework will oversee the execution of proposals as it’s transparent and enforceable through an approved spending proposal by the Layer 1 contributors.
Compensation requests must be accompanied by a formal governance proposal and submitted for community voting after the code has been reviewed and merged.
Review Process
Reviews will be conducted within a stipulated timeframe of 7 business days or less.
Reviewers are responsible for providing constructive feedback and may request modifications before approving the contribution.
Proposal Submission for Compensation
The contributor must create a proposal for compensation from the community pool after their contribution has been reviewed and merged.
The proposal should detail the work done, contributions made, and justify the request for compensation.
Disbursement of Funds
Upon successful approval of the contribution compensation proposal by community vote, payments will be executed to contributors respective wallet.
Payments will be made in the native token of Luna Classic ($LUNC) or ($USTC), corresponding to the compensation amounts specified in this proposal.
Path Forward
Community Discussion
7 Day discussion on Commonwealth for community feedback on the proposed compensation structure.
Incorporate community input to finalize the proposal prior to initiating the voting process with a revised version if necessary.
Voting Process
Initiate a governance proposal in a deposit stage after incorporating community feedback.
Ensure the voting process is transparent and accessible through community known platforms.
Implementation
Once approved, implement the compensation framework.
Monitor outcomes and adjust the compensation structure based on feedback from the community and contributors, providing an updated version as necessary.
Conclusion
This proposal aims to create a transparent and equitable compensation framework for Layer 1 code contributors within the Luna Classic ecosystem.
By requiring contributors to submit compensation proposals for community voting, we can foster engagement and ensure fair rewards for valuable contributions.
We are fortunate to have dedicated community members, who selflessly contribute to the Luna Classic blockchain’s development. Their efforts, while not obligatory, are vital for our future success. It is important for us as a community to seek effective ways to recognize and compensate these committed individuals, whose contributions often require personal time away from family and leisure. Let us unite to support their efforts, ensuring our members feel valued and motivated. Together, we can drive the ongoing progress of our chain.
Your support and participation are vital for the successful adoption of this proposal. Please provide your feedback and insights to enhance its effectiveness and sustainability.
appreciate the general idea of compensation, but I think this misses very important points.
contributions and with it review efforts are differing extremely. There will be contributions with 1 line change or 10 but also those with 1000s of lines changed. Which means a fixed compensation would either not work or just be taken for the smallest contributions for best gain-ratio.
The proposal is confusing. It states it applies to dynamic list management members, but on the other hand it states contributors, whose code is merged … which normally are people outside of the list. And mostly even done and compensated by PPJ.
The “Review Process” paragraph sounds like trying to enforce a mandatory review of list members during that timespan, which will not necessarily happen, especially on bigger contributions or those without certainty of implementation (not gov approved features or similar).
It states that contributors who submit pull requests receive compensation for the review, which is not making sense. contributors submit pull requests, but do not conduct reviews for this.
It states that spend proposals have to be done by contributors, but that makes no sense for reviews as those would need to be done by the reviewers in case they request payment.
For review compensation there is already the path of going via PPJ (like BLV just is doing), so this might lead to confusion about if that path is still valid.
That’s what came to my mind from reading it until now.
Cheers.
Thank you for taking the time to review the proposal and for providing your detailed feedback. Your input is invaluable, and engaging in constructive dialogue helps us refine our approach.
1. Compensation Structure Flexibility:
You mentioned concerns about varying levels of effort for contributions. The proposal aims to establish a baseline compensation to ensure we recognize contributions universally, but it is not intended to limit flexibility. Contributors are encouraged to detail their work in proposals, which could address any significant discrepancies in effort and complexity. The governance mechanism allows the community to adjust compensation based on these factors.
2. Clarification on Dynamic List Management:
The proposal indeed applies to members managing dynamic lists but also extends to other contributors to the Layer 1 code. The text can be updated to clarify this so that it does not appear contradictory.
3. Review Process and Compensation:
The intention is not to burden reviewers with tasks outside their scope. Compensation is for those who facilitate the code’s integration, recognizing the broader efforts of the contributors and assuring quality. The mechanism for reimbursements through governance ensures transparency and community involvement.
4. Alternative Paths for Compensation:
Rest assured, existing processes through PPJ remain valid. The proposal simply introduces an additional, transparent path for contributors who prefer the direct governance route. This can coexist with established methods without creating conflicts.
5. Review Timeframe Concerns:
While the proposal suggests a 7-business-day review period, flexibility exists for complex contributions. Reviewers and contributors will work together to accommodate larger or more intricate code changes.
Your perspective has helped highlight areas where the language may need clarification to reduce misinterpretation. We will consider these insights and potentially revise the proposal for better clarity and comprehensiveness.
Thank you once again for your constructive feedback. It is through collaboration and discussion that we can improve our processes and ensure they serve the best interests of our community.
Your 1. is exactly what PPJ does. So any dev or dyn list member can just post a PPJ with the outlined efforts for a review job with the amount of compensation requested to do that review.
I see no benefit in the wording/scope of this proposal compared to everything that is in place right now, contrary, to me it adds potential for confusion, controversy and different interpretation as it is right now.
Thank you for your continued engagement on this proposal and for providing your thoughts regarding the existing processes, particularly the role of PPJ. However let me clear a few things that might help you understand of the idea in context behind this proposal.
Distinct Purpose of the Proposal:
While it’s true that PPJ allows developers to propose compensation based on their outlined efforts, this proposal is designed specifically for dynamic list management members. Its purpose is to create a clear and standardized framework for compensation regarding code contributions directly tied to the maintenance of Layer 1 functionalities. The intention is to foster recognition among a specific subset of contributors while simultaneously facilitating community governance.
Intent to Streamline Processes:
We aim to streamline the process for dynamic list management members by creating a more direct compensation path. This proposal intends to clarify the compensation structure, making it easier for eligible members to understand how and when they can be compensated for their contributions without relying solely on existing mechanisms that may not specifically address their unique role in the ecosystem.
Addressing Potential Confusion:
Your concerns about potential confusion and differing interpretations are valid and have been acknowledged. Like stated towards the end of the text in this proposal, a revised version will be drafted as we are committed to refining the proposal’s language to minimize ambiguity. We appreciate this dialogue as it helps illuminate areas that may need clearer definitions or explanations, ensuring that all members can interpret the proposal consistently.
Value Addition:
It’s important to consider that while this proposal may seem similar to existing processes, it explicitly emphasizes transparency and decentralized governance. By mandating community voting on compensation proposals, it empowers dynamic list management members and encourages collective decision-making, reinforcing the principles of our decentralized ecosystem.
Invitation for Collaboration:
I welcome any suggestions you might have on how this proposal can be improved or modified to better address the community’s needs without introducing confusion. Your perspective is valuable, and together, we can refine this proposal to achieve our common goal of effective compensation for all contributors.
Thank you again for your input, and I look forward to your thoughts.
