Task Approval Committee and Terms of Service (TOS) #616
Comments
dckc
added
zz-Operations
I don't think a per-issue self-assigned committee addresses the concerns that have been raised around the bounty system. I suggest we use the people certified by the trust metric as the committee. (See also #375). |
|
@kitblake @lapin7 in the Apr 25 RAM notes (#614), I see:
I already created this issue. It's a bit frustrating that you didn't inform the meeting. I also see:
I'm struggling to find his github name to assign this to him. Also: another week is tricky... what rules are we using for April? The board's decision is reportedly effective April 6. Ironic: in yesterday's weekly debrief, Greg largely dismissed the Oct 2017 decision to burn RHOC as not actionable. The April 6 TOS decision looks that way to me too: the board didn't say who was to carry it out. |
|
ahh... I found ToddC's github name via rewards.rchain.coop: @Shakakai Thanks for your offer to build consensus on this issue... but... To re-iterate: "the coming weeks" is tricky... what rules are we using for April? The board's decision is reportedly effective April 6. As far as I can see, the officers are under no obligation to pay out invoices for April work if they aren't consistent with the board's decision. It's quite ironic that we would be expected to follow a decision from a meeting where the minutes aren't published, meanwhile. |
|
@ian-bloom the Apr 6 board minutes are now available. I don't see an effective date for the TOS in there. @lapin7 shall I turn off the trust metric for April? |
|
The trust metric has shown that it has good potential, for a decentralized management style of R&B and of result driven Issues. But not all the RAM's know how it's working and how we can influence the trust that we have in each other. So let's turn the trust metric OFF for evaluating the awesome work done in April. Then more RAM's are able to vote for R&B's!!!!!! The 9th of May the trust metric could be activated again. |
|
done: (adding a note in #375 too...) |
|
@dckc Great. First thing to decide is when the ToS are to be implemented. I suggest 9th of June, 2018. Then we have one month to get all the RAM's up to speed with the Trust Metric. |
Sorry, the notes don't show it but the discussion was to create an issue for Todd's initial research. But that never fully gelled.
Imho $0 is not right. But maybe that's moot now..
Ironic indeed, that's treading on thin ice. |
|
@lapin7 writes:
One path to reaching many RAMs is thru issue label guides (#401). Could I get confirmation from the following that you're following this discussion? Are you OK with composing the committee from the trust metric? Are there other proposals you find acceptable?
I have heard from the following recently:
|
|
|
@dckc is absolutely correct that getting some solution in the very near term is critical so as to have no interruption in the bounty program. @lapin7 is also correct that the RChain Cooperative wants a fair, responsible and decentralized system. I have outlined four principles below which may articulate RChain's goals with respect to the bounty system. In time for the next board meeting (May 1) we need to have a proposal to form the committee that conforms to the letter of the Board's resolution of April 6. In the month of June we can have a more in depth and more informed recommendation to update whatever we recommend on May 1. I would submit that the only way to meet these deadlines is to propose a temporary committee to carry out the letter of the board's mandate, namely an ad hoc review committee To accomplish this we undoubtedly have to rely primarily on the people with the most experience managing the bounty system, particularly @dckc and @lapin7, and others. The committee should also include some representation from people who have been compensated by the bounty system on a regular basis (ie they have been contributing productively using the bounty system). At least one member from the membership who is interested in governance (self nominate). We will also need someone like @Bill who has a background in HR and understands something of labor law and other legal requirements. We also need someone with a procurement background who understands how to make sure that proper value is delivered. We need to add some color to @dckc's statement that this issue will carry a $0 budget, that is true only for members who are not allowed to be compensated through a bounty issue because they are employees of the coop or already compensated in other ways. The important principle here is that members who use their time to work on behalf of the Cooperative will be compensated fairly. Principles of the RChain Bounty System
|
|
The documents of concern are now editable:
And related documents for Financial procedures. |
|
I am amazed at the progress of the bounty system since my initial
spreadsheets. I do not get paid from the bounty system but the bounty
system is part of my statement of work as well as my governance activities.
I am available to help in this area and am available to participate in any
governance related bounties I can find. I am passionate about evolving
decentralized governance and will help how I can.
I pray the trust metric is seen as sufficient control by the board. I've
yet to read the proposal am encouraged by what I see here. My thoughts are:
If having oversight can't be avoided presently due to perceived liability
issues we can decentralize oversight somewhat by delegating such oversight
to working groups related to the issue. A committee knowing nothing about
the issue is useless. The compensation committee might oversee the actions
of the working groups. This would have an effect of helping to keep bounty
tasks in line with the coop efforts. It would help bring people into
working groups.
However, I believe we should obey the sociocratic norm that if something is
safe enough to try, and inline with the goals of the coop, we should
consent to it such that the system is not brittle and can evolve. I feel
we need support education onboarding people into the new decentralized
world not limited by scarce money, the end of wage slavery and cooperation
at scale. I suggest building the community is as important as building the
software and we need not pinch pennies in that area. I worry that
commercial interest might lead us astray.
If oversight is forced on us I see the trust metric as valuable evaluation
tool helping working groups vet tasks, and a step toward complete
decentralization.
I am spread a bit too thin but hope to review all the docs soon. I have
been lax in entering and following governance working group issues in
github and will give my attention to it asap. I got to run but hope to dig
into this stuff this evening.
|
|
FWIW, this need not go on the May 1 board agenda. @lapin7 or Ian may bring it there, but otherwise, the executive committee has taken it on... and delegated further to Kit, Evan, Ian, and myself. |
|
@allancto writes:
See also #370 "Define "Purpose & Principles" for the RChain bounty program (RAM)". The result is enshrined in our README; in brief: Be a self-starter; Think for yourself; Get things Done; Morals matter; Be nice to each other. We could re-open that discussion and that issue, but I'd rather not. Let's please focus on how we're going to carry out the Apr 6 Resolution to Adopt Bounties Terms of Service. |
|
@dckc just reading up on the Board TOS change. So I'm following this discussion now. I'm not 100% sure I understand what you mean with:
Would that mean the trust metric and slashing setup takes the role of a committee? So slashing == task not approved, or something like that? If you mean just using the trust metric to determine who's likely candidates for the Trust Committee, then that sounds reasonable. But without trust metric you'd probably get to mostly the same conclusions. I feel like I haven't read up fully enough on this topic to have a good opinion, but my gut feel is that usage of the trust metric and a ToS change towards a task committee are components of a bigger solution, that should probably also include 1) better education & 2) expectations management for everyone that works in the bounty system. Part of the problem is minimising fraud & abuse, but an equally important part is enabling the most eager people to actually help. It feels like the 'enabling' part needs some thought, too. |
|
@pmoorman writes:
Yes, but again, let's please keep this issue scoped to implementation of the TOS decision. Onboarding issues are #253 (a continuation of #15) and the rest of the greeter issues. @lapin7 writes:
That seems reasonable; I'll see what I can do. |
yeah oke, good point |
|
I'm going to be a little blunt here, it's my belief that the TOS emerged from actually a different mandate from the board. I have tried to contact @evanjensen on this since he authored the document but we have not yet connected. (Evan, what's the best way to contact you?). The actual mandate to the board is to facilitate, encourage and ensure member participation in the activities of the RChain Cooperative, as required by both the cooperative structure itself (as well as by common sense). A cooperative is a legal entity based on member participation (ie cooperation / cooperative). This is a requirement morally, legally, necessarily (in terms of identifying issues and getting stuff done- @kennyrowe: "hierarchies are inefficient; knowledge is at the edges") and in terms of the principles and values we are developing- the RChain culture (@jimscarver , @kmoskowitz ). The bounty system provides a useful (and perhaps critical) avenue for members to participate. It also provides a simple metric- if you want to see which member contributed what via bounty system, just look at the bounty system records. At the same time mere participation in a bounty is not in itself a guarantee that a bounty will be paid (ie subject to review), because the bounty system has a fiduciary responsibility the cooperative to ensure that the asset brings value as well as participation. This was stated succintly by @ian-bloom in the 3/2/2018 exec committee meeting. Here are the minutes from Ian's comments as transcriped by @mrinalmanohar : It's my intention to elaborate on this theme, either within this issue #616 or in a separate issue if necessary, so that we are continuously evolving the Bounty System to serve the cooperative as it is intended, including "collective intelligence" from the RChain community as a whole and membership contribution from all members of the RChain Cooperative who are interested in participating. We won't solve this in a single iteration, but RChain was never intended to be a top down template, it's always been conceived as a work in progress that will grow organically and evolve to serve the membership. |
|
consolidated proposal: https://github.com/rchain/bounties/wiki/Task-Approval |
|
@allancto @Lover33 let's please focus our comments on the issue at hand here. This stuff belongs under #678. It's frustrating if an issue doesn't get the traction you're looking for, but Discord is a better place to discuss things, and keep Github issues focused. I would suggest we remove those comments, and keep this discussion on-point about the bounty ToS (which is complicated enough in itself already). |
|
@allancto writes:
Again: I disagree. If there is any more to your argument than an assertion, I'm interested to know what it is. p.s. by "#616" I infer that you mean not the issue itself by my proposal of May 2 on how to address this issue; to re-iterate:
|
|
FYI: @kennyrowe arranged a meeting last Tuesday with @ian-bloom and me. We learned more about each other's positions, but we didn't come to an agreement. Next step: May 25 executive committee meeting. Meanwhile, I'd appreciate 👍 or 👎 feedback on my May 2 "consolidated proposal" comment. I suggest the May 23 RAM meeting as a "speak now or forever hold your peace" opportunity... at least: that's one of the last opportunities before the May 25 executive committee meeting. |
|
@ian-bloom came up with an implementation of a centralized bounty system |
|
Here's an upshot of the EC meeting (my interpretation). There's still a lot of dubiousness about the bounty system in general and no alignment within the committee. In particular there are doubts about whether our decentralized approach to the ToS will solve the current and potential problems. We have another month to furnish proof. Therefore the long term report about the history of the bounty system needs to be finished asap, and the monthly report needs to be worked out. It'll be important to demonstrate the effect of turning on the Trust Metric for the month of May. Our efforts to create and share reports are welcomed. We can expect the results to get scrutinized, especially historical tabulations over the history of the bounty program. For the monthly report, the Label Guides will need to sync with the monthly rhythm in the planning (yet to be realized). |
|
Not sure where to put a general bounty system comment. Apologies for putting it here, where I believe the audience is right if not the issue number.
|
|
Interesting suggestions, @barneycinnamon . I suggest a new issue for each one. |
|
Based on discussion with @jimscarver and others following this week's RAM meeting, I revised the Task Approval proposal:
So all members of the committee are ineligible for bounty system rewards; we are compensated by other means. @ian-bloom I put you down as nominated; I look forward to syncing up to see if you'd like to accept the nomination. Likewise @PatrickM727 . If so, the four of us will become the trust metric seed. I can think of one other person who is likely to be a good candidate to join the four of us soonish. see also: 0008b8f diff |
|
@deannald I hope you'll accept the nomination. I look forward to talking with you about it. In a meeting, today, the EC agreed:
I make a revision of Task Approval to match. @PatrickM727 I think you don't get much choice. :) |
|
@dckc Yep, I'm down with it. 👍 We'll talk more on Friday and discuss what next steps are involved. @patrick727 Do you want to be included in this call (11 am PDT, Friday)? |
|
I don't expect the committee to have meetings... not regular ones, anyway. We'll be sure to communicate any substantive decisions thru bounty-contract issues. Deanna and I happen to have a call this Friday to talk about overlap of our newly-started SOWs, including the bounty system. I guess I don't mind if you join us. |
|
Please let me know the link to the communication channel. Zoom, Skype, Google or whatever. |
|
@deannald and I had a good discussion of this, along with @lapin7 . We presume we'll sync with @PatrickM727 before much longer. |
In the Apr 29 meeting of the Executive Committee, @dckc , @kitblake , @ian-bloom , and @evanjensen were tasked with coming up with an implementation plan for a resolution from the Apr 6 RChain board meeting:
Exhibit B is available in Apr 6 board meeting materials and in source form:
In the 20180411 RChain Active Member Meeting Ian reported:
though that was before the Apr 29 executive committee meeting, which set an expectation of resolving the implementation plan in the following meeting the week of May 21st.
Benefit to RChain
Carry out the decision by the board of directors. Address risks of collusion, fraud in the bounty system.
Estimated Budget of Task: ?? (executive committee work is volunteer)
Estimated Timeline Required to Complete the Task: a few weeks
Measure of Completion: committee is operational, tasks are getting approved / rejected, and Executive Committee approves the process
Related documents:
Related documents for Financial procedures.
cc @lapin7
The text was updated successfully, but these errors were encountered: