search

rchain / bounties

RChain Bounty Program
MIT License
90 stars 62 forks source link

Task Approval Committee and Terms of Service (TOS) #616

Closed dckc closed 6 years ago

dckc commented 6 years ago

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:

Resolution to Adopt Bounties Terms of Service

The Board discussed the bounty program terms of service drafted by Martin Davis.

A motion was made by Kenny Rowe to adopt the bounties terms of service, which was seconded by Greg Meredith. Greg Meredith, Ian Bloom, Kenny Rowe, Evan Jensen, and Hendrik Jan Hilbolling voted in favor. David Currin and Navneet Suman abstained. Accordingly, motion succeeded with 5 votes in favor and 0 against.

WHEREAS, having reviewed the previous bounty program policies and found them inadequate, new terms of service have been drafted and are necessary to address deficiencies with the bounties program, RESOLVED, the Board hereby adopts the bounties program terms of service, attached as Exhibit B.

Exhibit B is available in Apr 6 board meeting materials and in source form:

In the 20180411 RChain Active Member Meeting Ian reported:

New TOS for Bounty System effective 4/6/2018

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

dckc commented 6 years ago

In #615, @kitblake writes:

As part of a bounty system governance test, I'm inviting you to "assign" yourself to this issue (assuming you're actually interested). I could 'just do it' but assigning should be opt-in. Anybody else who's interested can opt-in too.

The idea is Github will preserve the assignees and then in the future it'll be easily and visually apparent who was a decision maker. This should overlap with the Budget/Reward system.

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).

cc @Jake-Gillberg @kennyrowe

dckc commented 6 years ago

@kitblake @lapin7 in the Apr 25 RAM notes (#614), I see:

We can make an issue and key people participate

I already created this issue. It's a bit frustrating that you didn't inform the meeting. Maybe the $0 budget isn't quite right. I don't know...

I also see:

Todd Cullen: need to do some research, gimme a week, come back on this call next week

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.

dckc commented 6 years ago

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.

dckc commented 6 years ago

@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?

lapin7 commented 6 years ago

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.

dckc commented 6 years ago

done: update pay_period set weighted = 0 where start_date = '2018-04-01';

(adding a note in #375 too...)

lapin7 commented 6 years ago

@dckc Great. Let's now discuss extensively the ToS before the board meeting on Tuesday, 1st of May and come up with a pragmatic approach that satisfies the board and the RAM's.

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.

kitblake commented 6 years ago

I already created this issue. It's a bit frustrating that you didn't inform the meeting.

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.

Maybe the $0 budget isn't quite right. I don't know...

Imho $0 is not right. But maybe that's moot now..

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.

Ironic indeed, that's treading on thin ice.

dckc commented 6 years ago

@lapin7 writes:

But not all the RAM's know how it's working ... Let's now discuss extensively the ToS ...

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:

lapin7 commented 6 years ago

One path to reaching many RAMs is thru issue label guides.

allancto commented 6 years ago

@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 that will work with the principles of the bounty system outlined below, and rapidly reach consensus on proposals submitted during June.

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 (proposed, to be edited with community feedback)

  1. Inspire and incentivize RChain Cooperative members to participate in developing all aspects of the RChain ecosystem.

  2. Obtain critical value for the Cooperative at reasonable cost.

  3. Ensure that the bounty system has fair and transparent budgeting and payment; fiscal responsibility and resistance to misuse; protect the Cooperative from "gaming" and other potential financial irregularities

  4. Evolve a decentralized system of governance which produces the results listed above in a rapid and harmonious way.

lapin7 commented 6 years ago

The documents of concern are now editable:

And related documents for Financial procedures.

jimscarver commented 6 years ago

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.

dckc commented 6 years ago

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.

dckc commented 6 years ago

@allancto writes:

Principles of the RChain Bounty System: ...

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.

pmoorman commented 6 years ago

@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:

Are you OK with composing the committee from the trust metric?

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.

lapin7 commented 6 years ago

@dckc wrote: 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.

Please invite me to the executive committee meetings, with respect to ToS

dckc commented 6 years ago

@pmoorman writes:

Part of the problem is minimising fraud & abuse, but an equally important part is enabling the most eager people to actually help.

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:

Please invite me to the executive committee meetings, with respect to ToS

That seems reasonable; I'll see what I can do.

pmoorman commented 6 years ago

let's please keep this issue scoped to implementation of the TOS decision.

yeah oke, good point

allancto commented 6 years ago

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 : https://docs.google.com/document/d/1MeYZFva1U-5Faf7NZmOrd0KeJ1CAc293sExC7Lxa4Ec/edit# IB: member participation in the ($$ moving around) is part of the justification of the coop [help, Ian?] IB: something like “participation is not a guarantee of payment”?

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.

dckc commented 6 years ago

consolidated proposal: https://github.com/rchain/bounties/wiki/Task-Approval with reference to https://github.com/rchain/bounties/wiki/Bounty-Task-Guides which is also new, and https://github.com/rchain/bounties/wiki/Trust-Ratings, which has been around for a bit.

barneycinnamon commented 6 years ago

Not sure if I'm posting in the right issue, but would it make sense for the Task Approval Committee to be made up of all of the functional area guides? Then the guide for a given functional area (roughly corresponding to current labels) could evaluate all submitted tasks and come up with a recommendation to the committee regarding which to approve (possibly with a recommended price), which to ask for re-submission, and which to reject. The TAC might just rubber-stamp the recommendations of each guide, but this would create a paper-trail to force the guides to think through their plan and connect their recommendations on specific tasks back to some overarching plan or heuristic. Maybe guides don't take any bounties for work in their area -- or even work in any area? -- but instead get compensated some other way. Not sure if that is necessary, and it does potentially cause other exploitable weaknesses depending on how "some other way" is carried out. I have some ideas, but that should be a separate consideration.

barneycinnamon commented 6 years ago

Just re-read Task-Approval in the wiki. It looks like the latest flow is:

  1. Contributor proposes task
  2. Within five days, committee reviews task
  3. If approved, task is posted
  4. Once it is posted, any member (or just the task proposer?) can submit a bid
  5. Within five days, committee reviews that bid; can compare bids iff a second or third submitted within five days of the first
  6. Instead of accept / R&R / reject, current plan is accept / reject, with R&R automatic for first rejection (is that better than three levels? simpler or more complicated? is some kind of referee report required with any of the above? referee report type thing would help proposer learn and would provide accountability trail for the committee)

What is the role of "The issues with non-zero rewards as a result of at least three committee votes represent approved bids." Is the idea that the primary evaluator needs to convince two other committee members to vote yes as well? In the guides as TAC approach, that could mean that the functional area guide makes a case to the committee and gets sign-off from two other guides rather than a vote of the whole committee, which would be good. What about no votes? Could a guide on the TAC vote $0 or even veto a submission they hate? We could say net 3 votes and could Ayes as +1 and Nays as -1. But that could mean more inertia unless it were a norm that vetos are to be used sparingly.

dckc commented 6 years ago

would it make sense for the Task Approval Committee to be made up of all of the functional area guides?

Largely; my specific proposal is: "The Committee consists of members certified by a community trust metric ... As a result, most Bounty Task Guides serve on the committee."

Then the guide for a given functional area ... could evaluate all submitted tasks and come up with a recommendation to the committee ...

That's the effect of "Bounty Task Guides should provide feedback on new issues in their area within a few days, both in the form of github comments and budget votes."

Maybe guides don't take any bounties ... but instead get compensated some other way.

That's been suggested before; my response is consistently: who are these people? what other way? I can tell you the names in the proposal I wrote up: the guides and trust metric seed have stepped forward and the community has certified around 30 committee members using the trust metric. We've all got track records and reputations you can vet right now. You can discuss specifics with us.

Full disclosure: I'm working toward a SOW starting June 1, so I don't expect to collect rewards after that. This is the case for some other guides and many of the certified masters, but not the bulk of the journeyers and apprentices, who typically do most of the work. (Reminder: those with a SOW don't collect rewards; I wonder if CONTRIBUTING is sufficiently explicit about that.)

What is the role of "The issues with non-zero rewards as a result of at least three committee votes represent approved bids." Is the idea that the primary evaluator needs to convince two other committee members to vote yes as well?

Yes. Much like we have been doing all along. And the primary evaluator should be a guide, but need not be.

What about no votes?

I expect "rejection" to typically take the form of discouraging feedback from guides and other community members along with a lack of supporting votes. If some apprentices approve work that journeyers and masters (of which most guides are) disagree with, the masters and journeyers get more weight in expressing how much the work is worth to the coop (currently: 7x and 3x respectively in weighted averages). If that sort of discussion and voting doesn't work, there are two further forms of recourse:

  1. Anyone who certified someone who is providing unfair input to the process should un-certify them.
  2. A participant loses their whole month's reward if there is a quorum of slashing votes against them on any issue.

I have yet to include slashing in the Task-Approval page... the Feb 8 design/story (implemented in 5943c69) is:

For further discussion of threat models and attack vectors, see #261 and #135.

kitblake commented 6 years ago

The idea of the Task Committee has been irking me since it was broached. What bothers me is it looks like a reversion to hierarchical central control. But I haven't bitched because I wanted to work out an alternative.

(Just in case: I'm well aware that the Bounty System has been gamed. That shouldn't be a surprise, nor is it a reason to kill the evolution and impose hierarchical management.)

What I would like to see is that the experts in a functional area form 'The Committee'. So if it's a Marketing issue, then the marketeers in the membership decide whether it's a worthwhile effort. If it's a Development issue, then the developers decide. Marketeers don't have a clue about development, just as (most) developers don't have any insight into marketing.

This would alleviate the problem of having a small committee of people, with different skillsets, judging proposals that are outside of their skillsets.

In the Task Approval doc @dckc puts a lot of pieces into place. By quoting the clauses from the TOS, the implementation specifics that follow are nicely elucidated. But I'm still not clear about the logistics of the Task Committee.

Isn't it better that, if one or a group of Members wants to get-something-done and creates an issue, it's their responsibility to convince enough Trustees to approve the issue? This would organically ensure that the experts in a functional area are the ones that vote.

ps: This suggestion can be expressed in code.

barneycinnamon commented 6 years ago

I am wondering if we could explore what it is about "a layer of middle management" that stimulates an allergic reaction. I suspect some of the tension between different visions for the bounty system relates to different views on the value of "management."

I have been thinking that academic journal peer review might be a useful model. There is an existing "literature" comprised of papers on a related theme. When an author submits an article, they attach a cover letter explaining how their paper represents a contribution to the literature. Usually, an editor reads the cover letter, reads the article, and decides to send it out for review or reject it immediately. If the editor sees it as a bad fit for the journal or very poor work, they reject it immediately. If they think it has promise, they choose two other academics whom they ask to read the paper carefully and write referee reports. Then the editor reads the referee reports, makes a decision, and writes a letter back to the submitting author explaining the editor's decision. Some journals invite submissions from specific authors whose work is known to the editor. Some invite proposals for contributions that precede the article submission itself.

I think we can see a lot of elements there that would be useful for our system. First, we want contributors to understand the functional area of the co-op to which they are proposing a contribution. This is like situating your article in the literature. They should have some sense of who else works in that area, what has been tried before, which efforts are ongoing, etc. Second, we want somebody to play an editor function so that contributors can get an indication in advance of whether a proposed task is perceived as valuable before they do the work and generate the deliverable. This is like submitting an unsolicited proposal for a paper rather than submitting the finished paper draft itself. Third, we want the editor to exercise judgment, and (I personally believe strongly) document their thinking on how the proposed contribution does or doesn't fit in. Some coordination is useful. Call it management or not, but there is no market here; we need some kind of firm-like elements to mediate these allocative decisions. Fourth, we want peer review: three endorsements is very much like an editor and two referees. The point is to have the community itself contributing the ideas for contributions, the evaluation of the contributions, and the contributions themselves.

A journal editor is not a manager per se, but they do fill a coordinating role to guide contributors and allocate scarce pages of space in the journal. Call it management, coordination, coaching, or curation. It's all of the above.

As far as the questions about who is on the TAC and how the trust network relates, the primary question in my mind is how somebody can build up their rating as distinct from a top-down flow as in the metric Dan used for inspiration. I am not saying the current metric shouldn't function as-is, but I wonder if it would be appealing to decentralize further by creating some path to genesis status; that is, a way for somebody to build up to having their rating directly rather than by flow from trust ratings from somebody with a higher rating. The current system has a whiff of aristocracy in the way that it could ultimately lead to an entire system of trust certifications that all flow back to a set of initial assignments made in spring 2018.

pmoorman commented 6 years ago

@kitblake I think in response to your bullets:

  1. Yes, that would be a big "committee", but they don't really need to meet or anything. They just vote, etc.

  2. Each issue falls into a functional area (= label), and each label has a guide. That person is expected to react, or take the lead.

  3. I think you're right. I don't know if there's any reason there couldn't be 2 guides on a big label. I guess I could share marketing with Patrick for instance, or something like that.

  4. It seems to me like there's a clear need for some form of "liaison between top and bottom" in the coop. Managers traditionally fill that role, but also setting clearer shared goals/targets can help for the bottom to understand what the top needs. There could be other things, too. Unless we have something else that functions, guides-as-managers is probably better than what we have right now.

cc @dckc

allancto commented 6 years ago

@pmoorman @kitblake @dckc @lapin7 , all.

I feel as a member that one thing you're missing big time here is that we need some experience and norms in how to recognize not only work but effort and value.

As a member of the Cooperative I want rhoc to be spent not frugally but wisely. There is a clear analogy with the currency of a country: when the country creates more fiat ("national debt") that's intrinsically neither helpful nor harmful, the result depends entirely on how the fiat is spent: roads and education and other projects increase the value of everyone who owns the fiat, corruption and poor processes decrease its value.

The bounty system is awesome, it's designed to turn individual member participation of TIME into VALUE for all the members of the Cooperative. The purpose of what we're discussing now is how to introduce systematic reward metrics that align contributions with rewards.

I think @kitblake recognized very clearly that the trust metric as constituted represents a system of committees and managers. That's fine for now: eventually it will evolve into a tokenized system of reputation and trust (yes, that means more tokens, not only rhoc, on the RChain platform, but that's going to become obviously necessary as we evolve).

But the key that's missing from all of our discussions is, how do we obtain the experience and knowlege of HOW to estimate value received? The bounty system can never be wise or fair until we have a process that increments our experience and skill in the practice of it. The issue isn't whether projects are pre-approved or post-approved, not whether we vote or appoint each other as trustworthy, the issue is how to establish norms for payment and norms for assigning value. These norms must align the interest of individual participants with the interests of ourselves as cooperative members. Surely our mechanisms have been only approximate to start but we are evolving them and refining them over time.

Let's start with some idea of how to minimally show our respect to individuals who participate and contribute through their time, who contribute skills they may have acquired in the past, who contribute commitment and devotion to following through on their projects. As we build a vocabulary for how to do this we'll gain experience in rewarding contributors in a fair, equitable and transparent way, and we will continue to produce the incredible value that our bounty system has been producing for the cooperative.

-Allan

barneycinnamon commented 6 years ago

Are SOWs made public somewhere? Is there any reason they shouldn't be? It seems like it would be useful for people who are considering submitting an SOW and for people trying to understand what the SOW-approving-authority-center considers valuable to the extent that the bounty system is expected to produce work that furthers the same (or a significantly overlapping) set of goals.

dckc commented 6 years ago

I feel as a member that one thing you're missing big time here is that we need some experience and norms in how to recognize not only work but effort and value.

I'm just trying to focus. We had explicit issues on such things:

The result was text you'll find in README and CONTRIBUTING and the wiki and such.

If, after reviewing those issues, you have information that we didn't consider, feel free to re-open them.

But meanwhile, please, let's focus on how to carry out the 6 Apr TOS resolution.

allancto commented 6 years ago

@dckc , I will review those, thank you for the issue numbers.

At the RAM meeting yesterday I suggested that the implementation of the TOS resolution should be to ask Evan Jensen and any other concerned board members what concerns they are attempting to address, and make a revised proposal by May 23 so that the board to consider our alternative.

We're operating here totally in the dark without Evan's guidance as to what he was trying to accomplish. I do not want myself or anyone else to speak for Evan, he's articulate and can certainly explain what the goals are. Furthermore Evan is inside counsel and a member of our board of directors. As a member of the RChain Cooperative, I believe it's totally reasonable to ask Evan to address us as members and explain what he's trying to accomplish with this resolution. Until that happens the board is just ghosting us, and that is NOT what the board of our cooperative or any cooperative is supposed to do. Neither @lapin7 nor @ian-bloom have made a statement representing the board's intent, it's possible frankly (reading between the lines) that even many of the board members didn't actually review the issues before voting on this. Certainly @lapin7 , who cares deeply about this matter, said he was blindsided, I expect other board members and executive committee members were as well. I will paste once more below the minutes from the executive meeting you attended on 3/2. I'm not sure what Evan meant by his introductory remark, "I’d rather have the process fixed first". It seems clear though that Ian literally suggested that the problem might be best addressed by adding a disclaimer something like “participation is not a guarantee of payment” (as i have begun doing in all my issue submissions), and Kenny suggested that your trust metric should mitigate "coalition of three" issues. For goodness sake, if we can design Casper we can certainly address coalition of three.

In the meantime I believe we should be doing exactly what we're doing now. This issue, #284, #318, #370 all address the issues as we understand them, that's exactly what what we should be doing.

As active members of the Cooperative I believe we deserve the respect of our board. I don't see that as having happened here. My narrative is that you and I and everyone who's trying to make this happen properly are being ignored and instructed to work without adequate direction. That's not right, not how we should be treating one another. Evan works for me and for you. Evan's concerns, deliberations, and consultations with outside counsel belong to the Cooperative, to us. Evan has been hired into a position of responsibility to us, the membership of the Cooperative. Is Evan performing up to your expectations in the role you hired him to perform?

Here are the minutes from our executive committee 2018/03/02. https://docs.google.com/document/d/1MeYZFva1U-5Faf7NZmOrd0KeJ1CAc293sExC7Lxa4Ec/edit# Previously: Evan Jensen to create an effective "terms of service" EJ: this is like a “help wanted”, yes? It shouldn’t be complicated, but I’d rather have the process fixed first. MM: is there anything that puts the coop at risk? In terms of seeing the RHOC as a security. EJ: I have significant hesitation about doing the bounty program. The risks around a coalition of 3 seem unacceptable. KR: the trust metric should mitigate that. IB: member participation in the ($$ moving around) is part of the justification of the coop [help, Ian?] RW: there is a “top down” payment decision in the end; that addresses many of my concerns. KR: hierarchies are inefficient; knowledge is at the edges [scribe enjoys the sermon too much to write it down;-] IB: something like “participation is not a guarantee of payment”? Kenny, Greg, and all recognize Evan’s advice and concerns Evan: I’m going to consult with outside counsel.

dckc commented 6 years ago

@kitblake writes:

Isn't it better that, if one or a group of Members wants to get-something-done and creates an issue, it's their responsibility to convince enough Trustees to approve the issue?

Yes, of course; sorry, I assumed that went without saying. The folks doing the work have a natural incentive to convince people to vote for them in order to get rewarded. The responsibility to approve the issue is shared between the contributing members and the guides (and the rest of the community).

How do we determine who needs to react? Aren't we going to run into the Everybody/Somebody/Anybody/Nobody antipattern?

That's a risk, but it seems manageable. We should add "get in touch with a guide early" to ISSUE_TEMPLATE (and take other opportunities to establish the norm). We should have redundancy in the guide role. Bounty-Task-Guides already encourages people to use meetings to get richer interaction if they're not getting what they need from github comments. Labels help connect issues and guides. Folks like @TrenchFloat watch for unlabeled issues.

If we use the Trust Metric and have 10 Masters and 20 Journeyers, is that a committee of 30 people?

Yes. That's about how many people have been actively participating to date, no?

dckc commented 6 years ago

On the analogy to academic peer review, I'll save for another time... but one thing @barneycinnamon writes is:

... I wonder if it would be appealing to decentralize further by creating some path to genesis status; that is, a way for somebody to build up to having their rating directly rather than by flow from trust ratings from somebody with a higher rating.

Greg Meredith started to say something about a decentralized trust metric too, one time; I haven't managed to talk with him about what he meant, but I'm curious.

I have a lot of hands-on experience with collaboration, but I'm really a novice in the whole field of economics and game theory. The advogato trust metric is something I have seen work in practice and it wasn't hard to adopt to the technology around here. Who knows how well it will work in our community... I'd like to think it will get us through the next few months until we can figure out something better.

dckc commented 6 years ago

@allancto writes:

Is [a board member] performing up to your expectations in the role you hired him to perform?

I'd rather that discussion happened under #564 Member/Board Mutual Agreement.

I have had my fill of your inflammatory comments, by the way.

allancto commented 6 years ago

@dckc I appreciate your situation and am grateful for your chastisement. I've edited my comment and removed some of what you found inflammatory, and thank you for pointing that out. I'll think further about the quoted comment, I agree somewhat that it's inappropriate to air this in public, but at the same time i think it's sometimes a requirement to assert that a spade is a spade. If Evan or other members know that it's not really really that way please explain to me publicly or privately- nothing would make me happier than to realize my comments are inaccurate or misstated and have the opportunity apologize appropriately.

Thanks @dckc, thanks all. -Allan

kitblake commented 6 years ago

@barneycinnamon I quite like the academic journal peer review model, and I've used the words "peer review" to describe the bounty system. The quality of academic journal publishing is something to which we should aspire.

And indeed, "three endorsements is very much like an editor and two referees". In that situation there are actually three peers, as the editor is also an expert. In our case, why would one of the three need to be an editor? If three Trustees approve, aren't we done?

Now, I'm not saying that we don't need a Guide driving the functional area labelled issues. That role is definitely needed. But it's not necessary that an issue has a Guide amongst the three Trustees.

Also (before you hit reply ;) see my reply to Dan below.

kitblake commented 6 years ago

@pmoorman (Fyi, I just stated above that having a Guide driving labelled issues is sorely needed.) Regarding my bullet point # 3:

...One person for all like labeled issues?

I think you're right. I don't know if there's any reason there couldn't be 2 guides on a big label...

But that one person goes on vacation, or gets sick, or burns out. I think we need not two, but three Guides assigned to each functional area. One of them plays the 'designated driver' role, but when necessary another can take over the coordination.

Not coincidentally, the three assigned Trustees match our our pattern-proven three peers.

kitblake commented 6 years ago

@dckc:

Isn't it better that, if one or a group of Members wants to get-something-done and creates an issue, it's their responsibility to convince enough Trustees to approve the issue?

Yes, of course; sorry, I assumed that went without saying. The folks doing the work have a natural incentive to convince people to vote for them in order to get rewarded. The responsibility to approve the issue is shared between the contributing members and the guides (and the rest of the community).

That's a relief. I was afraid we were going into a layers of decision making direction, where:

Weeks later, the proposal finally gets a go. But the conference it was meant to support has come and gone.

lapin7 commented 6 years ago

@allancto wrote in an email:

I am writing to you all because you were participants in yesterday's working group meeting and is apparent to me that you are all Active Members and active contributors to the RChain Cooperative. I'm including HJ, Ian and Dan on the cc because they have been principle designers of the system and I'd like to recognize them and also offer them as guides to using it (aka you'll be eating their dog food!!!!!).

The guiding principle of the RChain Cooperative bounty program is to provide a way individual members of the cooperative may share their time and effort for the benefit of all members of the cooperative. The mechanisms of the bounty program are a bit arcane- historically they emerged from the github developer paradigm of "issues" and "completion". The bounty system has been evolving rapidly over the last year or so, and it is still a work in progress, so please also consider contributing your effort to improving the bounty system itself!

In the meantime I invite you to register yourself into the administrative system as active, participating members so that you have the legal and infrastructure means to participate directly. Eventually we will have a way of defining and automatically registering all members who are "active", please contribute to making that happen! But for now it's still quite an involved process, involving registration in internal systems, jurisdictional taxation systems and so on, so please take the time and effort required to to go through the process.

There are two important DISCLAIMERS to add. In the bounty system, budgets are always "suggested budgets" until approved, and participation is never a guarantee of payment. There are several layers of fiscal control to ensure that the Cooperative receives value generally in line with rewards. These include a system of "budget votes" by members of the Cooperative. These fiscal controls are undergoing revision right now and will continue to evolve in the future (you're invited to participate in developing mechanism for fiscal responsibility). Also, the Cooperative has multiple mechanisms under which individuals may be compensated for value they contribute, and there are policies to prevent double payments for the same work, so if you're already compensated you will be expected not to receive bounty rewards for work that's already part of you job.

Thanks! Allan

How to register (again, difficult now but the membership will help evolve it to a better system as we go). Any questions or glitches, please address to HJ, Ian and Dan (and please cc everyone so we can track what the glitches are).

lapin7 commented 6 years ago

@allancto wrote:

There are two important DISCLAIMERS to add. In the bounty system, budgets are always "suggested budgets" until approved, and participation is never a guarantee of payment. There are several layers of fiscal control to ensure that the Cooperative receives value generally in line with rewards. These include a system of "budget votes" by members of the Cooperative. These fiscal controls are undergoing revision right now and will continue to evolve in the future (you're invited to participate in developing mechanism for fiscal responsibility). Also, the Cooperative has multiple mechanisms under which individuals may be compensated for value they contribute, and there are policies to prevent double payments for the same work, so if you're already compensated you will be expected not to receive bounty rewards for work that's already part of you job.

I suggest that these several layers of fiscal control are merely a technical check. The results have to be expressed in PKI's and the RAM's are using those PKI's to evaluate the votes on budgets and rewards.

It's always easy to control well defined work scrupulously and have less eye for vague work that happens in the top of the organization. Let's not become penny wise and pound foolish!

lapin7 commented 6 years ago

Some statements for the discussion:

dckc commented 6 years ago

I heard somebody refer to the trust metric as something I came up with again this morning. Every time that happens, I wonder how I have failed to communicate where it came from.

Raph Levien and company came up with it in 1999.

I wrote:

The advogato trust metric is something I have seen work in practice ...

The original Advogato site has gone fallow, but thanks to the editors of the advogato article in wikipedia, I found that it's been resurrected:

http://advogato.p2b.tv/ http://advogato.p2b.tv/trust-metric.html

My profile is still in there... http://advogato.p2b.tv/person/connolly/ connolly is currently certified at Master level. Name: Dan Connolly Member since: 2000-07-11 16:05:27 Last Login: 2018-04-24 17:48:18

IOU an update to the Trust Ratings wiki page to add a link so folks can easily experience the original Advogato community.

ghost commented 6 years ago

@dckc Until I searched for the trust metric online, I didn't know what it was either. Imagine that I am in the Free Software/Open Source space for more than a decade.

pmoorman commented 6 years ago

@kitblake based on your 3rd bullet point from 20 messages ago.... (hehe)

I think we need not two, but three Guides assigned to each functional area. One of them plays the 'designated driver' role, but when necessary another can take over the coordination.

Not coincidentally, the three assigned Trustees match our our pattern-proven three peers.

I think it could work to have 2 more "peers" (to borrow from @barneycinnamon ) act on each functional area.

Does that mean we can spin out an action item (maybe in it's own issue) to find a 2nd and 3rd person for each functional area?

I would add that maybe we should start with 2 for each area, but strive for 3. Two people is enough to guarantee 3 votes (submitter + 2 peers), and it's probably the "MVP" for the real solution.

pmoorman commented 6 years ago

@lapin7 could you elaborate what your conclusions or questions are, with the 3 comments above? I'm unsure what exactly I'm supposed to respond to, or agree/disagree with.

dckc commented 6 years ago

Does that mean we can spin out an action item (maybe in it's own issue) to find a 2nd and 3rd person for each functional area?

I don't think I understand the question. It seems obvious that you can make plans to find a 2nd and 3rd person to guide Marketing, I can do so for Development, you can help me, and vice versa, and so on for other areas. If issues help organize the work, very well. What information is this question seeking that is not already plain?

pmoorman commented 6 years ago

Good point. Here's the issue I just created => https://github.com/rchain/bounties/issues/672

kennyrowe commented 6 years ago

To be clear the coop will not hold payment of bounties while these issues are being sorted out.

dckc commented 6 years ago

@lapin7 wrote:

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.

Meanwhile, @kennyrowe and, I think, @ian-bloom have expressed support for Bounty Task Guides in light of the discussion in #672 . @Jake-Gillberg and @kitblake and I were OK with turning it on as early as April. I think @jimscarver expressed support in a RAM meeting for giving it a trial by fire.

So I just turned it on, at least provisionally, for the 201805 pay period. Let's see how it goes. I'm also making a note in #375 and #261.

dckc commented 6 years ago

In May 9 governance meeting minutes I see:

... Ian stated that he believed issue #616 did not comply with the TOS voted on April 6th to update the bounty system. ...

Well, my position is that the proposal I wrote up May 2 above does comply with the Apr 6 TOS decision.

This issue as a whole invites discussion of any plan. I haven't seen any specific alternatives. What plan do you prefer, @ian-bloom ? Who do you propose should be on the committee? How should it make decisions? When should it start?

@evanjensen also owes us input on this issue.

I tried sending email April 23 and May 2. I tried the #exec-committee discord channel May 4. I'm still standing by for a reply.