NEO Core Developer Work Guidelines (Draft) #2955
Comments
Jim8y
added
discussion
The rest is ok, @Liaojinghui. But, honestly, I think it is still a little far from a guidelines I would like to see. Too much things here you are trying to impose. In particular, I think that 2 and 3 are the best ones in your description. You should go in this direction I think. |
|
@vncoelho I did not make this list, its a collection from the neo ecosystem. Something we can discuss, but something we have to put there, not up to me, lets wait for other's opinions. Exit and force review is necessary to make sure that no prs get unreviewed for years (some prs waited for 2.5 years), and is not up to me to remove them. Again, i do not make any decision here, i am just someone put every suggestion together. New core developers will be added, we can vote on this. |
|
@vncoelho I think these guidelines are not only about how to approach work as a core developer but also how to organize the core developers and the processes they use to work together. @Liaojinghui, for the points that contain voting I would make it clear how the voting works. E.g. 4. Solution Voting on Disagreements: |
|
7- I think that is needed. |
one month for review, not for development.
personally not against it. But some sort of encouragment is necessary. Companies do this for a reason, a reason of humanity. No fund for developers, no boost for developers, no grand for developers, but all blame developers, you can do it, i can do it, but how about other developers? how about attracting more brilliant developers? Without the best developers, without the best project. |
|
I agree with what you mentioned about point 10, @shargon. Incentives, in the past, were worst. It looks like a good, fixed and stable reward/salary will be enough to keep the current developers and attract news ones. There can be levels of rewards/salary according to experience and contributions, off course. That was in line with some recent suggestions I recently sent to Neo Foundation. I still think that, from that list, what is really important are points 2) and 3). If we go in that direction we will already improve a lot experience, because PRs will be opened after a previous agreement on the issue and precise descriptions. |
Could you give me one example of a company who pay by individual incentives the gross of the income? Bonus is different than incentives and we are not a salesperson 😅. |
Then please tell me how are we evaluate the performance of developers? Every one get the same even by doing nothing? A Again, this is not about you, not about me, not about vitor, or roman, it is about the system whether it can attract good developers and treat them fairly. We can ask neo to pay everyone of us 30K USD per month, then everyone will be happy and you will do your job, but what about those who dont work at all? Or just do very small amount of work? It is possible in the future when we have other core developer. Its a system thing. I can understand how much shargon love neo and is willing to contribute, but you should not expect others do the same. |
|
Hi,
What does 'taking' mean? How is task distribution going to work?
Ok. How do they know it has been decided?
There must be a template for this or some way to measure if the PR has enough information about it. Also, shouldn't this information be on the issue, and not on the PR?
What configures a disagreement? A thumbs-down?
Ok. What defines approval? How is the discovery and planning process for the core devs?
By documentation, you are referring to inline docs, right? I don't think devs will create external documentation.
We should have an alumni program for ex-contributors. They should not be just 'terminated and excluded' but transformed into former collaborators.
Ok
One month is too much. Can we start with 1 month and plan to reduce it to 14 or even 7 days? Actually, can we make it this forced review just on PRs that are inactive? (no comments or updates). It doesn't make sense to force a review on something is being discussed
I suggest that incentives increase with constant activity. For example: If you contribute every week, you have right to '100%' of the reward. If you contribute only just a month, you have the right to only 30%—something like that. We need to ensure developers are coming back daily/weekly.
Ok |
FIRED 🤷♂️. If you want to attract talent, talent require stability. |
core developers who wish to address the issue can ask for it, post his solution. if no other core developers ask for it, he can work on it. Simple issues, a few lines to fix as shargon mentioned, can be directly fixed by the core developer who take it first.
we vote, we count, the vote result is public.
issue can be simple since it just describe the general idea. Pr will be more detailed since it is realated to implementation. Asking core developers to have a detailed design on an issue will consume too much time since things offen change during the implementation.
This can be decided, thumbs up and a heart for example.
vote defines approval.
I am considering adding document to the monorepo, we must keep the document up to data. I dont want to update document neither, but we must do it for the good of neo.
this is not up to us, maybe join the technical committee?
Some prs contain too much to review, 1 month for those large prs, 7 days for small prs is reasonable.
We are still discussing on this. But this actually not up to us as well. |
Stability, in the mean while incentive, who will reject? To be honest, stable salary for a web3 talent would require a lot of money. Just check the average salary for a Web3 developer in USA, neo will go bankrupt if all get paid "stability" |
Then don't expect them if they are your target when you say "attract talent" 🤣. If you want to be full-time in something you need to pay your bills with that, and incentives sometimes are no related with your work at all, one line could spend 2 minutes or one week. And also, after this week, another core developer was faster and push his version before you, then you will be frustrated and at the end you will leave it. Stability is mandatory. |
How to have a fair incentive plan is another question than Whether should we have an incentive plan. Please consider others as ordinary human beings, not someone like you who loves neo. I know you will work full time on neo if paid decently, but, can neo core maintaining rely on your own? No other core developers are needed? What we need is a system, not a personal love, a system that forces (encourages) people to do their work. |
|
What if it is: We are not salespeople, but we must reward people by performance/results. Otherwise, the system may become unfair, moving people away from Neo. |
Looks good to me. But consensus node must be voted by people... |
7 is necessary in my mind. We should have a punishment mechanism to push people to work. |
|
Push people to work,@steven1227? |
|
well, if you still have no idea, neo core is almost a dead project, almost no one is using it. if we keep it this way, it will be dead for sure. issues and prs left there for years, never heard in any other projects, all of us are to blame. |
Depending on how complicated we want the financial incentive structure to be, we can include all of the above into it.
|
|
@lock9 Consensus Node is a good idea, but... it can't be done with a multisignature, we can't have a consensus node that require to sign the block by different wallets, so it will be owned by only one, also it require voting power. But I think it is not normal for a single consensus node to earn more than all the core developers combined. |
|
I really dont want to disappoint anyone here, but incentive or base salary actually is not up to us. All consensus nodes are already distributed among communities and every commuity has a good reason to keep it, it is hard to get one for the core devs. |
|
Hello. Note: The process is still incomplete. We don't mention discovery, planning, and testing activities, but let's try to do this in small steps. You guys still need to decide:
Important: I can tell you that @Liaojinghui is doing the work as a developer and product owner. Developers want to code, not make plans. He is going to feel exhausted soon. |
|
The problem with the issue, as it is, is that we are discussing processes and governance together. Some processes are related to governance, but not all. So we could narrow down this issue to only discussions around the development process. Voting on issues is part of the process, so I would leave it here. However, compensation, termination, and the consequences of not doing 'mandatory' activities should be decided elsewhere. |
|
I made some changes to the original proposal. What do you guys think? Development Process Guidelines
|
|
@lock9 much better than my version |
Thank you very much @lock9 for your kind caring, its very nice of you. Things like this wont last for long, as lone as we have a solid plan for everything, we nolonger need to worry about them. As to the vote,
|
|
@csmuller @shargon @vncoelho @steven1227 @lock9, when i discuss the core-devs can have a fixed salary, but in the meanwhile, it should be the community to decide whether a coredev deserve a bonus by donating him privately. Consensus candidates gets a lot of gas, they can decide by themselves whether they want to give a small portion of their incomes to the coredev team seperately and privately, totally by themselves and no one should blame anything. We can setup a coredev donation website that statisticly shows our information, our activity, our donation address. |
|
N. Closing an issue requires core dev consensus. If an issue is closed manually, there MUST be a comment describing how and where it's fixed or why it shouldn't/can't be fixed. A bit similar to https://github.com/nspcc-dev/.github/blob/master/project-management.md#issue-closure |
Yes for the So, a reason of "inactive for too long" would be given the next time i close those issues (4 years old issues only i promise). a workflow of "close stale issues" maybe name: "Close Stale Issues"
on:
schedule:
- cron: '0 0 * * *' # Runs once every day
jobs:
stale:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
- name: Mark stale issues and pull requests
uses: actions/stale@v3
with:
repo-token: ${{ secrets.GITHUB_TOKEN }}
stale-issue-message: 'This issue has been inactive for 30 days. It will be automatically closed in 10 days if no further activity occurs.'
stale-pr-message: 'This pull request has been inactive for 30 days. It will be automatically closed in 10 days if no further activity occurs.'
days-before-stale: 30
days-before-close: 10
stale-issue-label: 'stale'
stale-pr-label: 'stale'
|
Those old issues doesn't hurt us, we should close them with a valid reason |
|
Isn't 3 years of no one touching a good reason to close an issue? I dont understand, you keep it open yet you dont care (many years no one follow), and you dont want it closed,,,,,,, I think an issue that no one follows for over 3 years already means its not accepted. And old issues do hurt us, cause we should check them one by one to make sure we dont miss valuable issues that contain bug reports and feature requests. For those already proved of no interest, we should close them, instead of leave them for another 4 years. |
|
I don't think we should close it. I think we should review all of them. Most of them can be closed, maybe 70%, but there is a lot of important feedback that shouldn't be forgotten. Some issues on Neo Express and the Debugger are years old but still relevant. From #2949:
Let's not close them, please. I can prepare a report so we can do this quickly |
@lock9 that is exactly why i wish to close old and not important issues. We need to close "70%" unimportant, then focus on "30%" that are important. going through 300 issues is not as easy as saying it, may take many years if we have to rediscuss them again. So, what i prefer to do is close those that looks unimportant, then reopen those that are miss closed. |
|
I understand your concern:
However:
|
|
Then why not just close them, then reopen on demands such that everyone who are involved can join the process and save us time on those old old old issues. Anyway, other coredevs also prefer your way, so I don't want to argue, I will always respect the majority. We may always have disputes, no need to convince anyone, just respect the majority. Let's focus on fixing issues. |
|
Hi everyone. Please check #2969 You can read it easier here: |
The problem is that some people like @roman-khimov and @shargon think we should only close it with a reason. Let's try to streamline the voting process: go into the issues and instead of closing, add your vote following something like this: 👍 : +1 - Keep it open, add to the backlog |
|
I've tried doing this for 10 minutes and regretted it. I think we need some initial work to be done. There are a lot of good discussions that should be considered. |
|
I think we should have agreed with @shargon and @roman-khimov to not close issues without a good reason for those ancient issues. So we can move on this way. |
this is from @lock9, i think he presents the guideline better than me.
Development Process Guidelines
Voluntary Issue Assignment:
Issue Discussion Before PR:
Descriptive PR Submissions:
Solution Voting on Disagreements:
Voting on Self-Submitted Issues:
Comprehensive Comments and Updates:
Reporting Breaking Changes:
Draft Mode for PRs:
Timely PR Reviews:
bellow is the old version.
NEO Core Developer Work Guidelines
When new issues arise, core developers can voluntarily take on the task of resolving them.
Before submitting a pull request (PR), core developers must describe their proposed solutions in detail within the issue thread.
PRs must clearly describe the problem being solved and the solution.
If multiple core developers propose different solutions to the same problem, all core developers will collectively vote on which approach to take using a simple majority vote. The PR is only submitted after a decision is made.
Core developers can work on PRs for issues they submit, but the issues must be approved by a core developer vote.
Code submitted by core developers should contain detailed code comments. Related documentation, examples, and unit tests should also be updated to reflect changes in the code. And pr should never decrease the code coverage. This ensures the codebase maintains good records and accessibility for other developers, and consistency of features gets tested and verified.
Core developers who do not participate in reviews and votes for a prolonged period may be removed from their role.
PRs must be set to draft mode until ready for merge. PRs ready for merge require voluntary reviews from several other core developers.
If a PR does not get enough reviews within one month, all core developers must forcibly participate in the review process.
Incentives for core developers are determined by their activity levels, managed by NGD. Factors like voting, reviewing, submitting, opening issues and PRs, and participating in discussions may contribute to activity metrics.
Core developers must respect and adhere to the outcomes of the voting process.
The text was updated successfully, but these errors were encountered: