Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HSD development and maintenance #2

Open
nodech opened this issue Aug 25, 2021 · 0 comments
Open

HSD development and maintenance #2

nodech opened this issue Aug 25, 2021 · 0 comments

Comments

@nodech
Copy link

nodech commented Aug 25, 2021

HSD development/maintenance

  1. Name: Nodari Chkuaselidze
  2. Email: nodar.chkuaselidze@gmail.com
  3. Project: HSD Development and maintenance
  4. Github: https://github.com/handshake-org/hsd

Motivation, milestones and goals

My background

I have worked on bcoin and related projects (bmultisig, bledger,
bsigner) as well as bcash fork for quite some time (3+ yrs) and have
pretty deep background both in bitcoin protocol and the codebase.

Motivation

Handshake and related libraries all need maintenance and in some cases
essential improvements. There are very few people working on the
hsd itself and issues are getting backlogged.

There are currently several PRs that need review/testing before they can be
merged. Some critically important improvements still need to be ported from
bcoin since a good deal of work was applied to bcoin after the hsd fork.

Scope

The project scope is relatively big, Handshake encapsulates several
projects in itself: hsd, hsd-wallet, hnsd, hsd-ledger and multiple
components around these projects. The tasks for each project can be categorized
as: bug fixes, improvements, features, review, research. All of these
can be part of the scope for this contract or some of them.

These are summaries of the task definition:

  • bug - mostly small bugs that are not critical, some small bugs can lead
    to improvements if better solution is to rewrite some parts of the project.
  • improvements - Improving quality of the codebase for different reasons
    (performance, quality, tech debt, extending tests and etc.) - this are from
    mid-to-big sized tasks.
  • feature - Range of the feature is wide, so its' size can vary from small to
    big. It can be just extending API for easier consumption to implementing
    soft/hard forks.
  • review - Review is necessary for any of the above and is critical to the
    handshake project, even when reviewing simple bug fixes. In general,
    complexity of review depends on the complexity of the task and mostly
    scales linearly to that complexity.
  • research - Issues that fall into this category can be any of the above
    similar to review, but can't be easily quantified.

Priorities

Priorities are never static and can change depending on the feedback from the
users, investors, projects or from the community in general. It will also depend
on the length of the contract - as many of the important backports can't be
accomplished in small timeframes and may only allow for bug fixes and reviews.

I will try to list couple of priorities that I think are necessary. It may
change with further involvement in the project or from the feedback.

There are some optimization research that needs to happen to the fullnode
codebase, that became apparent in the last PR I was working on: blockstore. That
is essential in order to outline the changes necessary to benefit from
blockstore, checkpoints and possibly some future improvements to the codebase.
It may lead to the improvement implementation.

There are small or moderate sized PRs backlogged that will only
get harder to merge as time goes. Every change introduced to the codebase,
makes it harder (depending on the PR context) to merge old PRs,
so I believe it would be good next step for the hsd codebase.
This mostly includes bug fix types or small improvements and is
in the review category mentioned above.

Issues on github need to be categorized, because they fall in range of the
categories described above(applies to PRs to some degree), but as priorities
go - bug fixes first and then improvements and backports.

Backports are, mostly, the biggest in size and depends on the contract length,
but also one of the most important improvements to the codebase. It applies
to hsd as well as hsd-wallet.

Next will be non-backport type improvement/features that are big in size
and may not be critical right now, but will become important as the chain
size grows. There are some in issues, that may lead to improvements or
discover new ones with more research and feedback.

hnsd also has several big PRs as well as important issues pending to be
fixed. Priorities in hnsd are similar to hsd, where bug fixes are the
most important in order to ensure services that are using it don't get
held back because of it.

There are also important features and improvements pending in the PRs,
testing needs improvements. Issues are same as in hsd - they fall in
many categories and some need research.

Contract

Previous big project I worked on was backporting blockstore from bcoin
to hsd, we had milestone of two months - but it became apparent that without
improvements to the codebase it would add to the tech debt(migration PR).
So the timeline got extended but funding did not, which left me in undesirable
position. That's the main reason this application is not project based but more
open and hopefully will scale with the contract length.
It is also hard to come up with set of issue/PRs as a project without
research or may not be good enough as separate project even if it fills up
the time. Some issue/PR may need several back-and-forth communication in the
review process and is done better with more open contracts.

I am flexible with time logged per/week and the way we communicate about this,
from part-time (20 hours per week) to full-time (40 hours per week) and any in
between. I would like to get paid 60$ per hour, also open to communicate on this
further.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant