I’ve got a more thorough post-mortem coming soon™, but one thing that came out of our first round of GMC discussions was a desire for…I don’t know whether to call it clarification or further action or something like that…from the community/pDAO in regards to how we fund “support”. By support I predominantly have in mind the support that people provide in the #support channel on Discord and similar things of that nature.
Inasmuch as the RP protocol is going to pay for support, it is going to come from the pDAO. My sense as a community member is this is a thing that most of us (myself included) think we should be (generously) reimbursing volunteer support personnel for. Support is different from many other potential line items (e.g. marketing, bizdev, research, coding) in that it is likely to recur in every single period and in roughly the same form. In that sense it is perhaps more similar to liquidity incentives (IMC) stuff than the kinds of grants the GMC was otherwise deciding on.
The GMC found it very difficult to decide how much to pay the support-related retrospective award requests this past cycle, including difficulty in deciding how much of our overall budget should go to support and how to weigh the contributions of the two people who submitted RAs (plus the potential other support folks who didn’t yet but may submit one in the future).
One thing that came out of GMC discussions is that it would be great if we could have a broader community discussion about how much we would like to spend of the pDAO’s overall inflation every period on “support” and whether that money should be coming entirely from the GMC’s budget, from GMC + reserves, from trimming IMC, etc. If the funds are coming entirely from the GMC, it would make the GMC’s life a lot easier if the committee knew roughly how much the community wanted spent on support payment every cycle.
The other thing that committee struggled with was determining how to allocate the support payments. In his RA request, Patches proposed number of messages in #support as a rough metric, and Object then based his request on his relative number of messages compared to Patches. That’s probably not the exact thing we want to be incentivizing in the future (e.g. pure message counts) but I think I can confidently speak for the GMC as a whole in saying that no one is interested in becoming the managers of #support, figuring out who deserves what share of the support allocation by monitoring that channel or other locations where support is provided. I think we are open to ideas on this front, whether that be the creation of a Support Management Committee with its own support budget or other metrics that could be used for apportioning support dollars by the GMC.
Any and all discussions related to the above would be most welcome!
Is there any kind of ticketing system we could use? Some user comes and makes a support ticket, someone else picks it up and finishes with them, support person leaves a ‘billable time.’ At the end of the reward period, a set amount of inflation could be divvied up by the successful ticket completion hours per contributor.
We would rely on the honor system with potentially a recourse for an appeal if you think someone lied and inflated their ticket hours. With how tight nit support tends to be, I think this is a minor issue.
One the one hand, a ticketing system like Zendesk is probably the industry standard for support use cases. On the other hand, it feels like introducing a lot of administrative overhead in managing tickets. It does make time and effort spent more measurable, but I wonder if that really is the problem that needs solving most. We have a couple of users very active in support and many who incidentally drop by to help out. For such a small number of ‘support personnel’, the honor system of estimating hours spent could work well enough (with # of messages as a very rough measure as ‘proof’ to back up the estimate.)
An entire support management committee feels overdone as well, but I understand the GMC has enough to do and doesn’t want to micromanage support as well. We could decide a percentage (or absolute amount) of the GMC budget as a maximum recurring support budget and a hourly rate, and then allocate from that based on hours reported by people providing support?
Unlike many here, I have no programming background so my solutions tend to be decidedly low tech. But here is mine:
Have a central pool where all funds for support go. (in my dreams, it’s a 2/3 multisig with Patches, Object, and me, since I’d be doing it for free and patches/object have already gotten GMC funding and may donate some of their initial payouts). This collects funds over 3 months.
Every quarter have a pinned message on a thread in #support, which gives an emoji for each person offering support (ie, patches object etc). Anyone can also post in that thread to add a person to the support list.
The message will read something along the lines of:
Please click the emoji for the individual that you feel provided the majority of assistance for you today. If you would like to contribute to funding #support, the recommended tip is 10% of the money saved or 10% of your time saved based on how much you think your time is worth. Please send donations to SupportTipjar.eth [or whatever]
Have a bot which sends a message in #support every x hours (2 hours? that’s usually enough for most to see without feeling obnoxious) that refers any people who feel they’ve been helped to the pinned message.
At the end of 3 months, the GMC either sends a predetermined lump sum or a matching percentage of community contributions to the tipjar. the tipjar is split between the various support staff based on their relative votes.
Pin a new message. Any support staff with less than 5 votes the prior round are taken off.
Some benefits:
the tips can be anonymized, ie your public discord can indicate support for 0xfornax because they publicly helped you, but your tip would not be linked to that interaction.
pseudo sybil resistant: if there are support providers who seem like they are receiving a disproportionately large share (ie, concern for cheating), it is relatively easy to audit who voted for them and check whether actual support was provided.
smoothing benefits: single large contributions get spread amongst many members. Similarly, one donation transaction can efficiently fund multiple individuals
Anyone who does not want to donate can still show their appreciation to the #support staff who helped them, which will funnel funds their way.
Some downsides:
May encourage less knowledgeable or less helpful contributors in the hope of tips (this is probably true for any way of reimbursing support)
Inefficiencies: if patches helps someone 5 times in a quarter, he can only be acknowledged once for that person
only for discord members (although this is where it almost all support happens)
People can just go into the pinned message and vote for people they like. this should be discouraged.
I really appreciate all of the thoughts so far. I do worry that for many of the people who provide support, one of the reasons they are willing to volunteer their time is that there is very low overhead for tracking what they do. They pop into #support when they can and do what they can. At a minimum, I think something like @Pieter’s idea of a set budget percentage would help a lot. I was actually thinking that maybe if the community has a preference for that amount, we could apply for a bounty during the next round of applications for support payments. Sort of a standing bounty of X% of GMC budget per quarter, with people able to claim the bounty once per quarter at the end of the quarter. That would still leave the question of how to apportion said bounty. I like @Pieter’s idea of an honor system reporting of rough guess of hours spent on support that quarter. @epineph’s bot/react system is also pretty interesting and seems fairly straight-forward.
I’m in favor of the honor system… It doesn’t scale forever (depends on a lot of trust), but it’s a wonderful method while it does. (aka - I agree with @Pieter).
The honor system is definitely the simplest, and I agree with a set budget from GMC that they don’t have to discuss every quarter, but I do worry about alignment of incentives. Namely, it’s based on what the support provider feels their time is worth, rather than trying to approximate the value they provide the community.
#support BadEpineph takes 2 hours to solve a problem that patches would solve in 5 minutes. Patches would get paid 5$, but epineph gets paid 120$ (which since it’s zero sum, this reduces patches’ income). Is this a concern?
Who will be responsible for policing overestimates of time worked? This will be touchy because it is a tight knit community. and we tend not to like to ruffle feathers (except oDAO plumage).
Is there a whitelist, and if so who will be in charge of gatekeeping who is allowed to provide support? Do we keep #support slim and trim, or permissionless?
However, if the major players in #support give their approval (they will probably be the most likely to underestimate their hours because of the challenge of tracking large, irregular schedules for 3 months), this seems like a great start and well worth funding.
2 - The supporters should talk among themselves if they think something is off. If they are unwilling to, or they can’t get it figured out, they can ask the GMC to cease payments or file a dispute on the next iteration.
3 - I think the previously paid supporters can gatekeep - so “low bar permissioned?”. I think we have the same safety nets as in 2.
GMC can cease payments
If a majority of the GMC agrees that a grant recipient is failing to provide the specified services to the protocol in a timely manner (as documented in the original application and in subsequent monthly updates), the GMC SHALL publicly announce such a decision and cease any future payments. This decision MAY be disputed by anyone through the creation of an RPIP within two weeks of the GMC’s announcement. The RPIP SHALL be subject to a snapshot vote.
Anyone can file a dispute
Anyone MAY file an RPIP disputing a grant, bounty, or retrospective award within two weeks of the announcement of recipients. Such an RPIP SHALL be subject to a snapshot vote.
1 - This one’s a tough problem, at RP and major companies . I suspect that supporters would tend to want this help even so, but perhaps some of the more active folks there (@Patches@objectObject@fornax) can give their thoughts.
Trying to synthesize the above. I think a bounty would work a bit better than a grant support in this case. Structured something like as follows:
Assuming this application was submitted on Apr 1 and funded effective May 15, it would look something like:
Recurring bounty worth 1,000 RPL per quarter (this is approximately 10% of GMC’s budget every quarter - other proposed percentages are welcome!). GMC creates a forum thread every quarter on the 15th day of the final month of the quarter (e.g. June 15). Anyone who provided support during that month can post in the thread between June 15 and June 29 with an estimate of the time they spent on support and the nature of the support they provided (#support, forum thread, twitter, DMs, other?). Any community member can also chime in if they think the estimates sound too high for someone or (more likely) too low.
GMC then calculates on the last day of the quarter (e.g. June 30) the share that each person gets of the 1000 RPL based on their share of the claimed hours. Payout goes out on July 1 and we start the next quarter anew.
This does run into the issue where people claim more hours than they should, but personally I’d rather start assuming everyone is acting in good faith and modify as needed rather than being overly complicated in trying to ensure accurate estimates.
This recurring bounty structure is a good approach, I think. First impression of the 10% budget sizing is that this quite significant, especially as it will happen every quarter. Support is very important, but we do need to keep enough budget for everything else we’d like to fund.
One thing though - this bounty is a maximum so it would not necessarily be fully paid out every period, depending on support hours spent. We also still need to determine a hourly rate for support to close the loop - any suggestions? (If hours spent * hourly rate exceed the maximum bounty, the payout per person - and effective hourly rate - would be reduced accordingly.)
For reference, in the first period 2330 RPL was spent on support payments, but this was of course retroactive over a longer period of time (any estimations how much this would be, normalized to a single period? That’d give us an initial ballpark figure for our periodic budget. Preferably we’d also have some slack in the budget to account for growing support requirements as the protocol grows.)
Agree with @Valdorff this is a tough one to tackle. Not even e.g. a ticketing system with a per-ticket reward alone would be of great help here. You could start classifying types of support requests somehow and move away from hourly compensation. Not a simple path.
For now I don’t think it’s a big issue, as people generally know where they can help out effectively, and others can chime in to help tackle tougher issues faster.
The 10% was based on doing what Pieter suggested in terms of estimating it. The committee awarded 2330 RPL out of a built up budget of approximately 42000 RPL, which is approximately 5.5%. However, that was only given to two people and there were presumably others who contributed to support over the past year (though likely not at the same rate). If we assume that Patches + Object account for 60% of support then that would give 9.2%, which I rounded up to 10% for idiosyncratic reasons. I imagine you could tweak that number down or up a bit, but something in the 7.5-15% range feels right to me.
I agree with the idea that the bounty is a maximum, but the more you lean into that idea the less this actually does for making life easier for the people on the GMC. My guess is that if we set a bounty at X% of GMC inflation payments for a quarter, the GMC is going to award the full X% and, to be fair, that is my purpose in starting this thread.
I’m realizing I never replied to this, which is probably because I don’t really have any good suggestions.
On compensating #support
I don’t think the “helpers” are going to be able to come up with a good system. I’m there because I’ve acquired skills completely orthogonal to the abstract ones need to solve this; I’m not good at this sort of stuff. All I can offer is some information about my experiences, which I’ll keep brief:
We didn’t do ourselves any favors by being “platform neutral” in the guides. I think Raspberry Pis were probably a mistake. We should have also dissuaded people from using OSX with Docker Desktop- it has been nothing but trouble lately. These users are disproportionately present in #support.
The vast majority of questions asked in #support have been answered before. I’d probably prefer to see bounties paid to people who provide self-help resources, like PRs to add content to https://rocketpool.support and the official docs repo.
The lack of search functionality in the official docs repo is hurting us. Most people don’t want to ask for help. They only ask for help when they can’t find resources on their own.
10% of the cases take 90% of the time. It may make sense to clock support cases from start to finish and not worry about compensating the long-tail of quick fixes. I’ve spent days to weeks working with a few NOs, and the grueling cases are really the only ones that make me question why I keep doing this. Helping someone, say, delete a swapfile is like lending your neighbor a muffin tin- I don’t think we need to worry about capturing that effort.
I think the regular helpers could probably do a better job coordinating with one another. The async nature of some of the problems people face makes us waste time somewhat regularly- eg- helping someone who has already tried a handful of things with another helper, and going through the same paces again.
At the end of the day, though, I think we would benefit from some light data mining. I can’t tell you how many times I told people that sync progress of 100.00% is actually rounded up from 99.999% before it occurred to me that I could just submit a PR to remove that confusion. If we were running a company, we’d have postmortems and ticket labels and all that good stuff, and we’d be working to prevent the need for hands-on support from arising in the first place.
I don’t know how to fix the disparity between ad-hoc volunteer-run casual support and the kind of work that needs to happen to reduce the burden and scale to a larger pool of node operators, but I think that’s what we need to focus on compensating. Of course, we can and should continue to compensate both- but paying people for hands-on support is not anywhere close to as efficient as paying people to prevent that work from needing to be done in the first place.
Ramblings
At any rate, I don’t intend to ask for more compensation for hands-on support than what I have already received. There are a few reasons for this:
I’m not in there as often as I was in 2022.
I need to work less or I’m going to go completely bald and my partner is going to kill me. I somehow have a full-time job still, on top of everything else. I’d love to give Rocket Pool my full attention for a while- there are a lot of things I want to build- but between cost of living and my particularly hefty health insurance requirements, I’m not sure I can. I’m actively trying to figure this out.
I want to go back to building stuff, so that’s what I’m focusing the time I do have on these days. I’ve worn many hats in my career, but rarely the sysadmin hat, so while my time in #support helped me learn new skills that bolstered my primary abilities, there are diminishing returns and I am eager to get back.
The compensation I did receive was generous. Lacking for any individuals to thank, I’d like to say thank you all. Very much. Being part of this community has been a joy for me. That said, in #support, I feel like I’m punching below my weight. I feel like helping people one at a time isn’t an effective use of my time. I’d rather build things that help everyone at once.
patches 
object etc). Anyone can also post in that thread to add a person to the support list.
. I suspect that supporters would tend to want this help even so, but perhaps some of the more active folks there (