BUIP Proposal: Build and Maintain Trust in BU Through Transparency and Accountability

[emergent_reasons]

Objective: Build and Maintain Trust in BU Through Transparency and Accountability

Bitcoin Unlimited (BU) is an important actor with a long history in Bitcoin and Bitcoin Cash. It is in BU's and the network's interest for BU to have a high level of trust from stakeholders. One effective way to build and maintain trust is to work in the context of an accountability process that regularly establishes expectations, measures results against those expectations, and seeks feedback on next steps.


Definitions

• Accountability Process: As defined below.
• BU Actor: Any entity that is being paid by BU for time or activity, or that is responsible for executing any part of a BUIP. For example, officers, BUIP responsible parties and contractors (or the person managing the relationship with a contractor).
• Period: One month, repeated continuously.
• Expectations: Specific details about expected deliverables and activities.
• Results: Specific details about actual deliverables and activities, measured against Expectations.
• Public Document: A document in the public domain with some facility or reference for providing feedback.

Accountability Process for all BU Actors

1. On the first day of the Period, a BU Actor creates a Public Document with:
   • Results from the previous Period.
   • Expectations for the next Period and any longer term Expectations.
   • Discussion of how any relevant feedback during the last Period has been addressed. The depth of this is up to the BU Actor.
2. BU Actor executes their plan during the Period.

For most activity, this should be a public process. In the case of confidential information, the process must be followed privately with reporting to the BU President or another BU Officer in the case that the President is unavailable for communication. The receiving BU Officer must include some level of detail about such confidential Results and Expectations in their own Public Document.


Considerations

• The Accountability Process should be required for at least all compensated BU Actors.
• Occasional failure to comply due to complications can be ignored at BU Officer discretion.
• Repeated failure to comply should trigger review of the relationship between BU and the BU Actor. For example withholding payment, cancellation of contract or removal of position. BUIPs should be created where needed to execute such review.

 

[solex]

Thank you for your interest in BU @emergent_reasons. As you mention, BU has a long history in this space. Throughout all that time, we have been near the top of the list of orgs with transparency of operation.

I see your proposed BUIP as a framework for transparency and accountability and I do appreciate the thust of it. However, some terminology is difficult to parse. In five years I have never heard the word "actor" used to describe anything we have been involved with. We are a development organization, building a Bitcoin Cash compatible full node and associated functionality. Do you mean "developers" or other development teams? Is BCHN what you would call an "actor"?

Note that we already have a guiding document. The BU Articles of Federation [PDF] which can be found here: https://www.bitcoinunlimited.info/about/organization

Have you read this yet?

BUIPs have been raised in the past for changes to the BU articles although a higher threshold is required than for normal BUIPs. They do need to contain revised text.

Can you elaborate more on the motivation for your proposal?

 

[emergent_reasons]

Hello @solex . "actor" is just a more human word I chose to use than "entity". The intention is to include individuals, companies, NPOs, anonymous teams, etc. with a single word.

I have read the articles of federation. I am not specifically interested in modifying them. I am interested in establishing a way for BU to build and maintain further trust with the ecosystem, and ultimately the success of BU's mission.

One recent example that shines light on the issue is the IFP. For whatever reasons, just or not, the ecosystem did not rally behind BU as the immediate alternative to ABC. Ignoring the very high bar of a multi-mining node culture which has not yet been strongly established, it would have been ideal for the ecosystem to rally around BU based ultimately on trust from users and pools. I believe this proposal is an important part of working toward a BU that has that level of trust.

 

[solex]

I have been thinking about your valuable comments @emergent_reasons. You are right that regular reports do help with community trust.I will say that we, at BU, have always tried to follow the high road, doing what we are saying, which is delivering both a quality and a multi-functional full node product. The client we have on offer is suitable for BCH miners, exchanges and business users.

If I can be perfectly frank, the problem with community perception of BU has been the measure of Amaury's success in wasting no opportunity to denigrate our team and software for several years, first privately, then later, publicly. As you can understand, much of this ad-hominem was delivered when he was the one with a position of trust in community, lead dev of ABC, so the tarnish has stuck to a degree even though trust in him has since gone through the floor. You will recall the Bitcoin Cash conference we both attended at Townsville, where everyone made a positive presentation except one. That exception was Amaury and he concluded with an attack on BU, even dredging up a research paper which I believe was an academic hit-piece on BU funded by Core Dev supporters when we were trying to get onchain scaling in BTC. At the time Amaury had to be introduced by David Allen, because he had fallen out with with the conference MC, Vin Armani. He was also the only person to refuse conference branding on his slides. Such petulant behaviour shows his true character. Now it looks like he will be finally sidelined, and hats off to @freetrader and the dev community who have done so much already to wrest BCH from the dead hand of ABC. Unfortunately, for BU, we are still suffering the effect of the multi-year attack on our reputation. I am determined we will overcome it, and I am pleased to advise that we are moving forward with @singularity's BCH Block Party initative, which the membership has just approved, We will be funding a BCH development hackathon, with prizes, scheduled before the end of this year.

 

[Jonathan Silverblood]

[...] the problem with community perception of BU has been the measure of Amaury's[...]

I disagree with this. I love BU and what it is trying to achieve, but BU is lacking in both transparancy and accountability.

I am determined we will overcome it

You can help create a self-fullfilling prophecy by actually addressing the concerns raised, instead of assuming that they are not valid.

 

[Jonathan Silverblood]

@solex What is required from @emergent_reasons in order to make this a BUIP to be voted on?

If it needs sponsoring, I'll sponsor it.

 

[emergent_reasons]

I appreciate that BU aims to be a transparent and accountable organization. I would expect nothing less. To put the issue into contrast, if I look at recent BUIPs, and I would like to know:

• How did this go?
• Was it executed efficiently?
• What were the difficulties?
• What were the results?
• What lessons were learned?
• Did the person responsible for execution of this BUIP accomplish what I would expect for <x> amount of money?
• etc.

I am unable to find this information. It is low hanging fruit from an organizational perspective to increase trust. Additionally, when I look at recent BUIPs, I would like to know in more detail:

• What are the specific requirements and deliverables for this decision, especially if money will be invested in it?
• What kind of reporting will happen so that contributors to BU know how their money and goodwill is being used?

It's good to know those ahead of time, but it is not realistic to know all the details up front. An iterative approach is natural for a lot of problems. This is where an approach of reporting as described in this proposal allows for measurable goals to be set without needing to specify every step.

Please understand I post this with the best of intentions for BU. A BU with more visible accountability measures to gain trust and participation is good for everyone in the BCH ecosystem.

 

[Griffith]

@emergent_reasons

Conceptually this BUIP is fine. Good suggestion. However, I have an issue with your implementation because I dont think it aligns well with the BUIP process. Because all official deliverables and org actions require a BUIP, I think it would be better if your accountability process were applied to the BUIPs themselves rather than to "actors" and should be applied to most BUIPs, not only those which request funding. This can be accomplished through a stricter BUIP system that has more deliverable requirements.

I dont think immediate action BUIPs such as BUIP 154 which take effect when the voting period closes need reports.

Open ended BUIPs such as BUIP 128 that dont have quantifiable deliverables are hard to report on. This is analogous to the issue of measuring productivity of development teams in a corporate setting. in general this is an unsolved and well documented problem. Regular reports are probably not best suited for these types of BUIPs. Gitlab data and the changelogs published with client releases probably suffice as an alternative to reports for these BUIPs.

Everything else could have a report requirement.

 

[Jonathan Silverblood]

> Open ended BUIPs such as BUIP 128 that dont have quantifiable deliverables are hard to report on.

Even if it's difficult to quantify, it would still be good to have some information on the progress being made - otherwise there is nothing to compare with and it will be much harder to judge what value is provided where.

 

[Griffith]

> Open ended BUIPs such as BUIP 128 that dont have quantifiable deliverables are hard to report on.

Even if it's difficult to quantify, it would still be good to have some information on the progress being made - otherwise there is nothing to compare with and it will be much harder to judge what value is provided where.

Ok, open to suggestions on this one. How to evaluate progress and allocation of resources in software development is a well documented issue with no clear solution in corporate environments.

what are you suggesting be used to demonstrate "progress being made"? the git log showing commits made? A point system similar to agile sprints? something else? This is why i was suggesting reports be applied to quantifiable deliverables instead.

 

[Jonathan Silverblood]

> what are you suggesting be used to demonstrate "progress being made"?

Anything that's accessible, digestible and useful. The simplest that comes to mind is simply writing a report in text.

 

[emergent_reasons]

Thanks for the constructive feedback @Griffith . As far as my proposal goes, I would be willing to add a clause about BUIP details, but I would not be willing to remove the detail that people acting on behalf of BU need to report either publicly or privately with a public placeholder.

The point is not necessarily to measure progress. The point is to transparently show what the intention is and whether that intention was accomplished or not, especially when anyone is being paid. This is the core of accountability. Judgement on whether the intentions are appropriate or not are a separate issue of leadership and management for the organization and other stakeholders. That is outside the scope of this proposal.

 

[Griffith]

Alright, I have tweaked my suggestion a bit.

The only way people get paid or receive funds from BU is through a BUIP which typically have requirements built into them. This is why i was suggesting it be linked to BUIPs themselves and not the person.

The suggestion is now that every BUIP (paid or unpaid) requires a report every period until that BUIP is completed.

This would potentially result in multiple reports from a single person if they are involved in multiple BUIPS instead of it being wrapped all into one report.

with the exception of the BUIPs that take effect immediately since there is nothing to report.

 

[Jonathan Silverblood]

The suggestion is now that every BUIP (paid or unpaid) requires a report every period until that BUIP is completed.

I think it's probably better that every person taking on work on behalf of BU (paid or unpaid) requires a (single) report every period. Requiring separation per-BUIP might end up unfeasable for people that are working with multiple long-running BUIPs.

I would like it though, if someone is working on multiple BUIPs but does not have any progress on the specific BUIPs, would make a section in their overall periodic report that lists the BUIPs that have not had any significant progress, such that they're not as easily forgotten.

 

[Griffith]

I think it's probably better that every person taking on work on behalf of BU (paid or unpaid) requires a (single) report every period. Requiring separation per-BUIP might end up unfeasable for people that are working with multiple long-running BUIPs.

I would like it though, if someone is working on multiple BUIPs but does not have any progress on the specific BUIPs, would make a section in their overall periodic report that lists the BUIPs that have not had any significant progress, such that they're not as easily forgotten.

This is the same thing as what i said.

one document sectioned for each buip or multiple documents each containing one BUIP, it is the same thing.

i just want it clearly divided so you can attribute each part to a specific buip

 

[theZerg]

This seems to be an operational BUIP, rather than a development BUIP so my comments are not authoritative.

One deep background thing that needs to be understood about BUIPs is that they generally constitute permission, rather than a mandate. This is part of the checks and balances of the system. A dev BUIP seeks a-priori permission for feature X to be committed to the repo. BUT someone still must go off and do that work. The BUIP does not generally mandate that a specific person go off and actually do it. This is important -- you need both the community to accept the idea, AND a dev willing to put in the grunt work to implement it (these checks and balances incentive is a little bit undermined by funding a BUIP, but that is a topic for another time).

This concept directly applied to this BUIP means that the BUIP provides permission for someone to go off and do it. But it does not require that it be done. Someone has to care enough to actually go off and do it.

And frankly, I'd argue that any member who wants to can access and publish this info today, simply by asking us or the person implementing the BUIP how things are going.

Cutting directly to the chase, my natural aversion to reports sees this monthly work as busy work, so I don't love the idea of formalizing something like this. And I wonder if a BUIP can constrain subsequent BUIPs in such a manner. Certainly, any subsequent BUIP could just override any such constraint.


But I think that this BUIP is coming from a valid place. To be completely honest, BU has kept an extremely low profile and focused on basic research over the last few years due to the extreme antipathy towards us exhibited by ABC in the interest of keeping the community relatively unified.

But who is going to read these monthly reports? Its too much information.

What I like about this BUIP is an idea that I can distill from it: "hey, we should create a page on our web site that details ongoing projects and make comments on progress".

What I don't like about it is the feeling that its a bunch of dry forms to fill out that few will read, and the implication in the word "accountability" that the true purpose of these forms is to catch some people "cheating". "Cheating" is a hard term to define in this context, since 1. nobody is working "for" BU, as opposed to consulting or service, 2. consequently there is no expectation of full time work, and 3. many of us are working far under our market rates if we did spend full time on BU.

 

[Jonathan Silverblood]

From my understanding, a BUIP provides three things:

• permission
• funding
• direction

BUIPs further is the mechanic that the members have to influence the organization as a whole.

In order for members to make informed decisions, they need information. Since BUIPs clearly aren't work-orders, members can refer to BUIPs themselves to understand what the organization is doing, for many reasons.

This creates a blind spot where members need to rely on trust in the organization, but since the organization doesn't have a mechanic to earn that trust it becomes a choice for the actors to do, or not do, "busywork" to stay in touch and maintain a healthy relationship with the members, and a non-choice for the members who either get to have insight and transparancy so they can make informed decisions, or make less informed decisions without that insight and transparency.

This has nothing to do with cheating: it is not a matter of micro-management, it is a matter of transparency.

From my understanding, BU seeks the wisdom of the crowd and has a membership that can freely put forward BUIPs and each member has voting rights regardless of their expertise - because BU wants to include the needs of a wider range of participants, not only the subgroup "node developers", or "protocol developers", but all kinds of users.

BU has been good to me over the years: I've used the full node software, I've gotten feature improvements that I've asked for and I've even been offered to do work when I was in a position where I wasn't sure that I would be able to go on if I wasn't paid.

But no matter how much I like BU, it is still somewhat of a black box to me, and I still get surprised when there are "drops" of new information for things that have been going on for months, and this is despite me trying to be involved. I hang out on both telegram rooms, I read this forum and I follow BU on twitter.

Given the discussion thus far, I assume that this BUIP should be reworded so that it directly alters the BU articles now. I doubt this BUIP will get anywhere though, since there seems to be a clear difference in perspectives and very few members have decided to be engaged and discuss it, so chances of reaching the requirements for a change in the articles would be very slim.

 

[theZerg]

Let's forget about whether this BUIP will or won't pass and explore what you actually want.

Does my idea to make a status page help you? If not, how can the idea be modified?

---

But note that "BU" developers are much more like co-researchers in many respects, and are absolutely not treated like employees. They are encouraged to delve into BCH and cryptocurrency related R&D that interests them, bazaar style. For example, Wally Wallet was not technically part of BU until this most recent vote. I developed it independently.

Are these pre-BU ideas what you want access to?

There will always be these kind of informal efforts that don't begin life in a BUIP or on a Gantt chart and learning about them means talking to individuals-associated-with-BU rather than engaging in analysis of BU's official projects. But there is no doubt that 3 years of friction with ABC, and friction with ABC apologists (people who engaged in blindfolded ABC cheerleading and excuse making -- and to be absolutely clear this statement is meant entirely generally, not towards you in particular), has made BU-affiliated individuals "once bitten, twice shy", so your luck in that respect may vary.

Additionally, my post here (https://read.cash/@AndrewStone/bch-looking-back-and-moving-forward-a703cbcc) was an invitation to anyone (BU members or non-members) to begin to engage in discussing future directions for BCH, and I threw down a straw-man proposal for that direction. The entirety of the feedback received (mostly in various dev telegrams, which I'm sure you also are part of, but also in responses) and loosely arranged by influence in the "new world order" can be summarized as follows:

1. There is no need for a roadmap or vision for BCH and any attempt to make one is silly in a decentralized effort.

2. BCH should be for BCH only, not tokens.

3. Great! (with no further engagement)

 

[Griffith]

Let's forget about whether this BUIP will or won't pass and explore what you actually want.

Does my idea to make a status page help you? If not, how can the idea be modified?

---

But note that "BU" developers are much more like co-researchers in many respects, and are absolutely not treated like employees. They are encouraged to delve into BCH and cryptocurrency related R&D that interests them, bazaar style.

Going to fight you a bit on the "busy work" aspect a bit even though i think i dislike taking the extra time to write documentation and explanations / reasoning for doing something the most out of anyone in the dev group.

The "developers are much more like co-researchers" statement is correct but the complaint this BUIP is trying to address is, with the exception of Peter R, finding the final details/report for a given area of research is not a trivial task. Even @Bissias who writes incredibly thorough BUIP's does not have conclusion reports for how those turned out unless there is an extension BUIP added to continue the work in which case he writes a fairly detailed report of what the first BUIP accomplished as supporting evidence for why a second one is needed. This is one of the major reasons why some people still think graphene is in development even though its development concluded in 2019. some sort of final report to conclude a BUIP is a good idea.

A status page would be an easy way to organise the final reports.

We also dont put out monthly progress reports which seem to be growing in popularity which is not related to this BUIP but it is related to the following feedback and its general sentiment

But no matter how much I like BU, it is still somewhat of a black box to me

 

[theZerg]

@emergent_reasons, @Jonathan Silverblood, @Griffith:

I tried to put into practice the ideas I described above. Please look at this page and give feedback: http://www.bitcoinunlimited.net/buip/summary

Thanks!