Funding Support Moving Forward

Governance
21

GMC is deciding on current retrospective awards, and I won’t speak directly to those decisions; this post is to discuss the precedents those decisions would make.

These are my positions that I think are reasonable:

  1. If GMC pays for these current awards, in addition to past awards, it can safely be assumed there is a GMC precedent to pay retrospectively for #support when requested.
  2. People working fewer hours shouldn’t be paid less PER hour based purely on that fact.
  3. There is some amount of commitment below which we have to assume this is a hobby and not “work”.

And my opinions that are very debatable:

  1. If we have the money currently, we should pay so as not to risk an insolvency crunch if RPL price decreases or resources have already been allocated elsewhere
  2. Work less than 1 hour per month can be safely categorized as hobby

Based on these and Haloooloolo’s RocketScrape https://discord.com/channels/405159462932971535/1212029664285954058/1219919904032034866, patches, object, d33too, poupas, yorick, haloo, lilac, ken, mig, ramana, bawcey, teamBerbere, invis, atomicwhale, snocones, steely, timJanssen, Blinc117, Pieter, LeighM have averaged more than 1 hour per month over the past 5.5 years; I have left off RP team members (joe, fornax, jakepospischil) and bots. I have not screened these members for use of #support for their own support.

This is a combined 4152 hours; at 90USD /hour, this is 373,680 USD of work done.

Subtracting 70k and 18.5k paid to patches and object, we have ~285k USD of outstanding liability.

As previously discussed, it suggests about 150k/year of support cost moving forward, likely more since there will be a precedent that the GMC will pay.

So I wanted to get a temperature poll on whether we should:

    1. Pay out past contributors at the agreed upon 90/hr USD rate (total 285k)
    1. Decrease pay per hour for all contributors
    1. Continue to do reimbursements as they are requested, and GMC decides with each request how much to pay each contributor somehow on merits
0 voters

Or for “OTHER” please comment below!

22

I’m not opposed to proactively paying all outstanding liability. But we’d need to make sure to a) have consensus on the parameters RocketScrape is run with to determine the payout and b) distinguish between supporter and supportee. Once we have both of these things, we could potentially transition to a monthly pot going forward, which I’d be a fan of.

23

I’m wary of a straight up hours in support * rate method of paying out for support help. Are there times when people in support just chat with each other? Is that a significant amount of time? Does this punish someone quicker at providing help?

I think it should be determined on a case by case basis until there is a more firm way to measure. For instance, a ticketing system (although there are likely other/simpler options).

1 Like
24

I’m closest to “Pay out past contributors at the agreed upon 90/hr USD rate (total 285k)”, but I think we could (a) play with the tool a little more to understand what makes for reasonable settings and (b) discuss a bit more on details like thresholds etc.

25

Yes, but it’s usually interleaved with actual support so it doesn’t really affect the metric. The trickiest cases are people that both receive and provide support, e.g. Ramana and Tim Janssen.

26

Once we completed the retroactive award, I would like to see a proactive (forward looking) budget and mechanism (e.e.g schedule, sign up, pDAO designation or Rocket Scientists or Support Specialist role, etc.) set to ensure that RP has a plan to provide for support services.

1 Like
27

Drive-by comment

Is there any kind of ticketing system we could use?

This is problematic bcs scammers. It is easier for users to grok “we DON’T have tickets” than “open a ticket but … NO NOT LIKE THAT!”

Solscan Discord for example just got rid of their ticketing system bcs users repeatedly couldn’t distinguish between scammer “open a ticket” and legit “open a ticket”

28

Ticketing would be invisible to the users, in my opinion. We’d just set it up for internal issue tracking. It would track effort by supporters but more importantly we’d be able to keep track of individual support journeys which would prevent duplicated work.

1 Like
29

Maybe “ticketing” could be as simple as a specific reaction emoji that the supporter uses on the supportee to indicate they are the one helping them. Admittedly, there would be some amount of trusting supporters to self-police.

30

This gets complicated on cases where multiple people contribute. Do we limit it to one supporter per ticket? If not, a) how do we measure who contributed how much and b) how do we prevent people from adding themselves to past tickets? This wouldn’t be noticed as easily by others and the Discord API does not seem to expose at what time people reacted.

31

Multiple people are not necessarily a big problem. Everyone who worked with a person could react. But I do agree that policing it for cheats is problematic.

32

I’m not very involved on this side of things, but it seems like it could be simple enough to track this internally (even a simple google sheet with controlled write access for people who want to commit to regularly helping?). People providing support can just update the google sheet/record a one line summary of time spent/link to the beginning/end of messages. I’m sure that could help quantify things later and maybe make looking up historical issues easier