Tasks that needed to be realised for dev branch (roadmap?)

[nspcc-dev]

Tasks that needed to be realised for dev branch (roadmap?)

[hal0x2328]

Right now the plan for all the award-eligible CoZ repos is to funnel tasks that have been tagged by the TPM (for neo-go that is me) with a low/medium/high impact to a public stream for visibility, starting with a Discord channel, then Slack, Twitter, etc. The idea being newcomers who want to become CoZ contributors would have a one-stop shop to see what tasks they could potentially start on today given what languages they are proficient in.

So if there are tasks that we don't want appearing in that publicized list because they need to be held off for whatever reason, we should either remove the impact tag, or add a second tag that can filter them out of the public feed automatically.

I personally like the second option, because I'm looking at Github daily for new tasks to tag to keep the project profile up, so leaving outstanding tasks without any tag is going to make it harder for me to track.

Also under this new system it's going to become important to declare you're taking a task by assigning it to yourself or at least commenting that someone outside the org is working on it, so efforts are not duplicated.

[kevaundray]

Good point. One way to organise the tasks, would be to create all tasks that would need to be completed beforehand, allowing anyone to open a PR and submit work. IMO this approach would work effectively with a dedicated team. A dedicated team would allow for multiple reviewers on different parts of the code without knowledge of exactly how the other parts work, as this is a modular architecture. Since the community is not obliged to work on an issue or continue working on an issue, I don't believe this would be the best strategy.

To give an example, if a PR was to be opened on the dev branch for block verification logic, then it would not be useful for our current milestone and best case would end up as code that needs to be maintained, worse case, code that needs to refactored dramatically.

For our circumstance, it would be better to move towards intermediate milestones and only adding PRs for those intermediate milestones. Once this milestone is completed, we would gradually add support for a new set of features giving rise to a new intermediate milestone.

Our current milestone is to have a node which downloads blocks, validates the invocation tx's through the vm and sends out the block/tx information to rpc clients. For this we would need to create the server construct, the vm and the RPC module. The RPC module was being worked on by @dauTT and I believe I asked if you could supervise. I have started on the vm until those who were assigned become available and the server is an open issue at the moment. There are also issues open regarding the VM if you want to try those.

WDYT?

If you need more information, then let me know

[hal0x2328]

Also I should mention that the public stream will only show issues labeled with an impact by the TPM for that project, since anyone in the org can potentially add any arbitrary label to an issue.

[im-kulikov]

@hal0x2328 If I understand you correctly, do you agree that there should be a list of tasks that could be taken by any member of the community, as well as newcomers?

[im-kulikov]

Perhaps the concept of roadmap in the title is confusing. I assumed that a list of tasks, perhaps with a description of the essence of the problem, we still need, do you think?

[kevaundray]

@im-kulikov You mean for example,in #167 and #168 Explain why we need a Map/Struct type as a stackItem or why we need an Equals method?

[im-kulikov]

Just description for task. So that beginners can quickly join the development.

[kevaundray]

Could you give an example of exactly what should be changed, based on an open task? Preferably one of the ones I mentioned above?

[im-kulikov]

I now tell about a non-existent problem. Those that can be started as an issue. Add a description, after reading which, the person could begin to solve it.

[im-kulikov]

It is not about the existing tasks.

[kevaundray]

**Implement OPCODE ADD in the VM** issue #9999

- We pop two numbers off of the stack as big integer 
- Check the errors
- Add them together with the Add method defined on BigInteger
- then push the return value back to the stack

You mean like this as an example?

[im-kulikov]

it looks just like for children. it remains only to write code instead of a person.

I had in mind...

**Implement OPCODE ADD in the VM** issue #9999
- we need OPCODE ADD IN the VM
- VM documentation - link
- C# code example - link

[kevaundray]

Okay I understand now.

The first point I believe is self explanatory?

Could you link me to the VM documentation? I think I missed it

[im-kulikov]

https://docs.neo.org/en-us/utility/sdk/introduction.html ?

---

UPD: https://docs.neo.org/docs/en-us/tooldev/sdk/introduction.html

[roman-khimov]

I think this discussion is obsolete now and should be closed. There will be tasks and roadmaps and everything else after we deal with the dev/master split (see #283).