SSB Maintenance

A process proposal.

Related:

• Maintenance sprints by @andrestaltz
• The Guild by @mix

Goals

• Help maintainers
• Attach no strings
• Clarify roles
• Get it done
• Make it work

Theory

Creating and releasing a software project or other resource creates a burden of maintenance that accrues to the authors of the project or anyone who takes on a role as maintainer of it. The burden of maintenance is the expectation of continued service to the users of the system, e.g. to fix bugs, answer requests for help using it, document and test it better or make other incremental improvements, and update it in response to external changes. A non-software project may also need maintenance, such as a written reference or website which needs links and content to be updated to maintain and improve the usefulness of the resource.

Assumptions

There is a source of funds for the purpose of SSB Maintenance. There is a person ("The Principal") on SSB who has authority to send these funds to people. The Principal wishes to send funds to people who are executing the responsibility of maintenance ("Maintainers"), to support them materially, out of joy and gratitude for their contributions and service to the users and the network.

Process

The Principal chooses two or three people (including themself: "The Allocators") to help them decide who to give funds to for maintainence and how much to give to each person ("The Allocation") [1]. The Allocators decide The Allocation in private [2] and then announce it publically [3]. They solicit payment details from maintainers newly added to the Allocation, and requests for changes [4]. Anyone may publish a Request for Change if they wish to be added to or removed from The Allocation, or have their allocated amount changed [5]. The Allocators publish acceptance or rejection in whole or in part of each request [6]. The Allocators may change the Allocation on their own or in response to a request [7]. The Principal directs regular transfers of the funds to the maintainers according to the Allocation. The Allocators publish changes to their group [8].

[1] The Principal may pick whomever they want. If they wish they may invite the public to apply or nominate people to be Allocators. I suggest they consider maximizing the social reach of the process by choosing people who are somewhat spread out in the ecosystem, e.g. not all working on the same project. But more important I think is that the Allocators should have good rapport with the with The Principal. And they should be active/responsive on SSB. The Principal may choose to remove themself from the responsibility of being a Allocator by choosing someone to take their place who consents to it and arranging for them to be able to direct the Funds.

[2] They may use any methods that they choose. They may consider personal and family need of the individuals to receive funds, regional variations of cost of living, perceived impact of the maintenance and projects, difficulty of the work, measurements or statistics about the projects' usage or size. They may issue and distribute a currency for others on SSB to use to assign votes or value to projects or maintainers. I suggest they do this in private so they may speak freely with eachother, but they may do it in public instead if they are all comfortable with that.

[3] They may also publish an explanation of how they decided the names and amounts, if they want to.

[4] They may do this privately or publically, individually or collectively. Maintainers may accept or reject allocation offered to them.

[5] To submit a Request for Change, a person publishes a message mentioning the Allocators in public or encrypted to them privately. They may provide justification for their request, appealing to what criteria if any the Allocators have said they are using as basis for deciding. For example, depending on the Allocators' criteria, a maintainer may request increased amount for themselves and cite significant growth of userbase of the software project they are maintaining, or cite increased personal expenses because of family obligations or changes in cost of living. They may request to be added to the list for maintaining a project that is new to SSB or one that they think the Allocators overlooked. They may request to give their funding to another person whom they have agreed with to transfer responsibility for a project. A requester is responsible for making sure their message will be seen by a Allocator according to SSB gossip. If they are not within close enough social radius to any Allocator, they may ask peers to rebroadcast their message so that it reaches the Allocators.

[6] The Allocators and the Requester may correspond in private or in public about a Request. If the request was made in public, the Allocators should make a response in public if they feel the request was made in good faith. The Allocators may ask the Requester for more justification of the Request or may give justification for rejecting the request in whole or in part. The Allocators should respond to a request in a timely manner.

[7] When the Allocators make change to the Allocation, in acceptance of a Request or otherwise, they publish the change(s), optionally their justifications for it, and link back to their previous change(s). They may sometimes publish the current Allocation, for the convenience of viewers, but it should always be possible to calculate the current Allocation from the history of changes. The Allocators may publish the changes and the Allocation in a structured way according to a SSB messages schema, or they may state it in markdown posts.

[8] If an Allocator wishes to no longer be an Allocator, they may announce that publically, or privately to the other Allocators. The Principal then chooses a new Allocator and announces it publically when they have accepted that role. It should always be public who is currently a Allocator, so that people know who to mention to make a Request for Change.

Decent! Do you have any opinion on the frequency of allocation decisions? And how long does a single grant last?

This is a really thorough suggestion for how to operate.
As I read it, I think The Allocation is a recurring payment (e.g. $50 per month for some particular human) until there's a change made by the processes described.

I think this is the clearest proposal so far and I would be happy for us to try this with a fixed budget from the Dfinity grant.

cc @mikey @elavoie @bobhaugen @arj @dominic @Alanna @noffle

The Allocators may at any time change the Allocation and publish the change. They may decide on an internal decision-making process [9] and Reallocation Schedule [10] for making changes.

[9] For example, they may decide that an Allocator may publish a change after proposing it to the other Allocators privately and receiving approval or acknowledgement of it from at least two of them. Or they may decide that any of them may make a change with or without consulting the others, according to some parameters. Or they may decide to defer changes to regular intervals according to a Reallocation Schedule. Or the Principal may solely approve and/or publish changes. If a Allocator other than the Principal publishes a change to the Allocation, they should have authority from the Principal to do so, so that people can be confident that changes published by the Allocators are valid.

[10] They may decide to periodically, such as every other month, reevaluate the Allocation, evaluating their criteria for each Maintainer and updating amounts accordingly. The reevaluation may include searching the SSB network for maintainers who newly fit their criteria, to offer them to be added to the Allocation. If a maintainer is no longer maintaining or otherwise no longer fits the Allocators' criteria, the Allocators may remove them from the Allocation, optionally after a grace period or after attempting to contact them to confirm if they are still maintaining SSB projects.

@andrestaltz the payments would be recurring but subject to change, as @mix said. So it should last as long as the person is maintaining SSB projects, while funds are available, unless the Allocators decide to limit payment based on other factors. Payment frequency is up to the Principal. I assume it would be monthly. If the process and payment technology were streamlined enough I would encourage trying a higher frequency.

For frequency/schedule of allocation decisions, my opinion is that this is for the Allocators to decide, as the work of allocation is theirs. They could use a monthly reallocation schedule to match the frequency of payments, and only make changes according to that schedule. Or they could try a reallocation schedule of 1 or 2 or 3 or more months, while also being responsive to requests for changes and make changes on their own between reallocations as they find appropriate. Or, they could try not having a reallocation schedule, and instead make changes in response to requests and continuous monitoring of SSB maintenance activity and/or other criteria. If they adopt a regular reallocation schedule, I suggest they consider deferring any decreases of maintainers' amounts until the next reallocation, to respect human psychological sensitivity to loss of expected future rewards.

I like this proposal. Thanks for taking your time to write this down @cel. It's clear you have been thinking a great deal about this. I've been thinking a bit about the differential allocation money aspect, overall I think its a good idea, I'd just note that its a big change compared to the ordinary grants.

You're welcome @arj. The proposed process does not require the allocations to be differential between people - they could all be given the same amount - but there would still be a differential between those getting some and those not - and also between those who get some for different durations or in different time periods, as the Relative Theory of Money discusses.
This process can be complementary to ssbc-grants, as a new project commissioned through ssbc-grants once in use may require ongoing maintenance.

I'm a bit confused by the level of detail given here - I see that the Allocator basically has full discression about how they allocate funds, which I don't necessarily object to, but I'm not clear on transparency/accounting side of this. I see mentions of Request for Change, etc, which sound good, but I think I need to see templates of what these Requests, and Changes, etc look like before I feel like I understand this proposal.

[3] They may also publish an explanation of how they decided the names and amounts, if they want to.

I think "may" is the wrong word here. If someone refused to say where the money was going to that would make me very worried. I'm doubtful any legal entity is allowed to do things like this aside from "petty cash".

I also worry about having "Attach no strings" in the goal list. Because we do have expectations and goals. I think more friction will come if we pretend there isn't expectations than if we are just explicit about them. I'm just talking about processes like keeping dev-diaries, though.

@dominic I withdraw the goals list.

Incorporating your suggestions:

[3] They may also publish an explanation of how they decided the names and amounts, if they want to.

The Allocators announce their goals and expectations of maintainers, and what their basic criteria will be for deciding amounts.

For full transparency, all communications may be public. I assumed that the Allocators would find it helpful to communicate in private to make decisions.

An option for Accounting: The Principal makes payments to Maintainers according to the Allocation, or assigns responsibility to do this to someone else; the one who does this is "The Payer". When the Payer makes a payment, they record in a ledger the payee name, date, amount, payment type, and the id of the most recent ssb message that authorized the payment or is otherwise most relevant to it. They store this ledger in a public git-ssb repo and push changes to it after making payments.

Template for request for change (new maintainer):

author: @maintainer7

Request for change

@allocator1 @allocator2 @allocator3 @allocator4

I would like to be added to the maintainers allocation. I am maintaining [project1](link) and [project2](link). Recent activity: %msg1 %msg2

Template for change (new maintainer):

author: @allocator1

Allocation change.

Added: @maintainer1  $400

[Explanation of change]

Previous change: %msg

@allocator1 @allocator2 @allocator3 @allocator4

Template for reallocation:

author: @allocator1

Allocation for 2018-01

@maintainer1 : $618
@maintainer2 : $382
@maintainer3 : $236
@maintainer4 : $146
@maintainer5 : $90
@maintainer6 : $56
@maintainer7 : $34

[Explanation of changes]

Previous reallocation: %msg1. Changes since then: %msg2 %msg3 %msg4

Allocators: @allocator1 @allocator2 @allocator3 @allocator4

@cel thanks! I have no problem with private discussions, as long as the decisions are public. Sometimes personal issues need to be resolved, and those are usually best delt with in private.