Work notes - HS/GH evolving the flow

I am applying the moto "what other services/modules/libraries that are even remotely reusable/generic if they were to exist would make the job of implementing my project trivial"... I reached the following realization.
substack:
Which hypothetical reusable modules would make the task at hand trivial?

When you do that the first thing that happens is that you find other modules that are doing something similar to what you need but not exactly. So then you have the following options:

 1 Ignore the existing service and do something simpler yourself that does just what you need 

 2 Talk with the owner to see if the needed feature/expansion of functionality is sth that makes sense for that module. If yes:

    a ask the module owner if they would do it. (Even if the person is willing to do it, you are often being blocked by the missing functionality which means you probably need it asap which makes that option... rarely an option

    b fork the repo and try to do it yourself

 - If no

    c you may still fork the repo and create a variant of the module that provides that new functionality and publish it 

2c and 1 are similar. However, only 1a is truly leveraging others. I think it is very important to figure out how to better enable 1a (as opposed to just allow someone to outsource the todo list of their own repo).

So here is how we could do that.

The existing model of HS/GH  is as follows.

- You register one repo with HS/GH

- You can request for any of the issues in your own repo to be od sourced (by providing some additional info around the issue (budget, tat, primary skill, secondary skills) (you can provide these info either as back-matter yaml in the issue itself or directly in an external system. By doing so the following things happen

   - The issue owner is charged the amount

   - An od job post that links to the issue gets created based on the information above

   - A pool of candidates get automatically invited

   - Applicants that fail to meet requirements are auto-rejected

   - The first applicant that meets the requirements is auto-hired, and their gh username is linked to the job, and the job becomes filled

   - On pull request from the the linked user the system confirms that acceptance criteria are met. If not user is notified that the issue is not ready yet.

   - When the owner accepts the pull request payment is being made and job closes

   - Meanwhile a issue progress icon is maintained that can displayed in the issue's markdown both to help the issue owner as well as to attract more/future candidates.

   - If time passes past the tat, notification is given to issue owner to extent the deadline or the job gets cancelled and the money is returned to the issue owner.

The owner is freed from the hiring/paying process.
The owner still has to manage the person, answering questions, reviewing the pull request etc. 

He can avoid some of that by putting more time in the issue details. 

He can avoid some of that by following strong unit testing, coverage, lint enforced practices etc.

Still he has to put a non-insignificant amount of time, limiting essentially the extent to which a person can truly scale themselves.

To enable muti-level scaling we need to better faciliate the 1 case above.

So here is an idea of how to go about doing that:

HS/GH also supports the ability to "pledge" towards the implementation of issues/features on a repo that someone is not an owner of (like sourcebounty .com)

You can pledge an amount of $s towards the implementation of an issue. 

To figure out how much to pledge you really need to ask the repo owner - how big of a job it would be for you to do the job (assuming guidance by the owner - which in most cases they would be willing to provide). The amount of hours x rate is an indication of the pledge amount.

A simple way to think about that (similar to what we did above with the issue yaml back-matter) is to allow a pledge to be given in the comment of the issue as comment back-matter yaml. Essentially you link a particular comment on an issue on someone else repo with a pledge (amount+ TAT). That does the following:

 - checks if there is already an od job for this issue. 

 - If yes it augments the od job with the extra pledge/amount/tat.

 - if not creates the od job as private and invites the repo-owner as sole applicant.

 - the owner accepts the invite (no obligation) and subsequently can do 2 things

   - creates (one or more related issue and gets it done by someone else following the model above

     (note that he now has the money to do that)

   - does the job themselves and makes the money

     - closes the issue

     - on issue close the payment is being made

 - the pledge should have probably room to allow the repo owner to make some money themselves (even if they outsource the job) to increase the motivation and get the job done on time.

This means that module/repo-owner would make money by resolving issues. The more users a module has the more issues it would create. The more modules someone maintains the more issues.

The model allows a developer to make more and more money by developing the stuff that want to be writing.