Closed ABISprotocol closed 10 years ago
"public reports" sounds good to me. The cost (converting useful work into bureaucracy) is probably worth the good side (allowing people to be aware of what they are supporting). However:
"Failure to post the agenda to the ... website shall result in postponement of the meeting." "The agenda shall be posted to the Bitcoin Foundation website at least..."
Just my humble opinion, but I think this can be more harmful than useful. I understand what you try to do here, but to my experience, such procedures can be blocking or waste precious time, sometime in extreme circumstances when the Foundation needs to react quickly (tends to happen often these days).
I didn't see any change related to "financial transparency" and I remember this was often suggested in the past, just in case you want to include something about it.
@saivann Thanks for the comment. Particularly given the many (which if counted would likely number in the some hundreds of thousands) of complaints about transparency, the least the Board could do would be to inform the broader public of what it intends to do in its meetings. I've drawn a bit from some of the mechanisms of the Brown Act in California, but I've stopped short of suggesting that there be consequences for Board members or staff for failing to do so. However, given the Board's recent headfirst dive into DC lobbying, and given the significance of (at least some of) what the Board does, I think it's very reasonable for: 1) public notice to be provided to everyone (and not just to members) of what would happen in advance of a meeting, via the website, and 2) that failure to provide that notice shall result in postponement. It's a very basic transparency measure which is used and well understood by what could only be described as a 'ginormous number' of similar bodies that make decisions about things.
The reason that there is no change specific to "financial transparency" proposed here is because transparency, in order to be effective, need not be particular to a topic. A good transparency measure covers the bases and thus ensures that any action that is proposed from decisions of a group such as this, is public. The other aspect of it is that whatever the decisions of the group are based on the agendized matters should also be public (in other words, there should be some brief record of what the decisions were and which way the axe falls based on the actions, for example, was there a vote 3-2 in favor of something). I haven't yet determined how best to reflect that in this pull request, but after contemplating your comment a bit, I've decided that I will go back through and add something to that effect.
@saivann In response to your comment I've added this to the pull request.
@ABISprotocol Thanks. Feel free to adapt your pull request or not, these are just suggestions, hopefully useful ones.
Is there any known advantage of reporting what "will" be discussed, when and where over just what "has" been discussed and decided? I felt the later was harmless, flexible and more informative. If I recall correctly, members can already ask for any subject to be discussed at any time?
@saivann Reporting or posting what "will" be discussed (e.g. an agenda) would help indicate, for example, whether or not the Board is responding to requests of members and / or the public for certain things to be considered. On the other hand it would help people generally understand what the Board is doing even if they are not interested in asking the Board to discuss or act upon a subject. To your other point of what "has" been discussed and decided (e.g. "minutes"), the advantage of posting the agenda before the meeting and minutes at some point after the meeting is that the minutes make clear what actually did happen ~ thus anyone who wants to can compare a block of months (or years) of publicly available agendas and minutes and determine various things about the operation of a Board, including, but not limited to, how well a Board is able to actually make decisions on issues that are brought to its attention where such issues are determined to need some sort of action, for example.
As an aside, I note that you've already read the source on this, but for those just diving into this, the first commit on this has to do with agendas, and the second one (Transparency-2) has to do with minutes, and they are so labeled.
For those interested, I've been informed that my pull request(s) will be added to the Bitcoin Foundation Board of Directors meeting agenda. I'm not sure if it will be on July 14th, or on the next available meeting date, and since I have two pull requests, it may be spread out over a couple Board meetings.
@ABISprotocol.
It will be interesting to see what happens. I have been quite busy, but some time ago it had crossed my mind that to bring the bylaws more into line with typical practice, three things should be added. First, a clause on the issue of moral turpitude. Second, a statement as to various disqualifications for a prospective or existing Board member. Third, a formal statement regarding the method by which a prospective board member attests to his qualifications at the time he runs for office.
I am of the opinion that properly worded these should be things basically nobody would object to.
Some of this stuff should be right out in the open, and I can't think of a better way to do it than putting it in the bylaws. Then again, to have a board which voted against including a very standard clause on moral turpitude in the bylaws, well...if an when that happened, that would certainly be interesting.
@mdhaze Hello, moral turpitude is not part of this or the other pull request I've authored. I'm not inclined to change the pull request(s) to address that concern. However, you are welcome to draft your own pull request for that issue, or open an issue for its discussion. Perhaps your ideas about disqualifications and method of attesting or stating qualifications should be expressed as a commit that is a component of a pull request you author, as well. For example, this pull request (#17) focuses on transparency, but has two proposed commits, one dealing with agendas and another that would, if accepted, layer in provisions dealing with minutes. I suggest you take a similar approach for any pull request you may author, and provide a commit for each distinct concept that is part of a pull request that you may author.
As an aside, if the Board opts to change the language of any commit in my pull request(s) (in other words, provides approval, but with a modification from the Board as part of the approval), then I would change or add a new commit to reflect the Board's approved language, which would then likely be reviewed by Patrick Murck, and then upon his confirmation that such changes would be consistent with what the Board approves, he could then merge the commit.
Currently the Board is considering my pull request(s), as I was notified of on July 12, so I'm not going to push any changes to my pull requests (the change on July 10 in response to @saivann's comments was the last one I'll make on these, unless I am informed by the Board that other changes are needed). When I hear back from the Board on what they have decided to do with what I've already submitted, whether they approve, deny, or approve in part with modification, then I'll come back to this matter.
Looks good.
@ABISprotocol
You said "Hello, moral turpitude is not part of this or the other pull request I've authored. I'm not inclined to change the pull request(s) to address that concern. However, you are welcome to draft your own...'
Just to clarify, I was not thinking of modifying this pull request but opening another and will do so. Sorry for any confusion.
I haven't fully reviewed these, but as a general comment, I think minimal pull requests, i.e. the minimum text needed to make a certain change, are going to be easier for the board to look at and analyze.
@vessenes I'm inclined to agree, although some things (like the suggestion for an agenda to be posted to the Bitcoin Foundation website) affect different and multiple sections of the Bylaws, and thus the changes must necessarily affect different sections of the Bylaws as part of the pull request. I've tried to make it as easy on the Board as possible for this particular pull request, by pulling apart the issue of agendas and minutes, so that agendas is one commit, and minutes are covered in the other. It's up to the Board to read and consider each commit that is part of the pull request, and the Board has options to approve, deny, or approve with modifications (and any modifications the Board would approve, I would be obliged to include as a patch or new commit, which would be subject to Patrick Murck's review for consistency prior to merge application).
The Bylaws are complex and even the smallest changes to them are going to (and do) affect multiple sections. You are going to have to evaluate the effect on the Bylaws as a whole by reading the whole document as it exists and as proposed. That's the Board's responsibility.
@ABISprotocol Anyone reading your proposed changes will read the first section, then the section then say "Oh, I get it, this is the same text repeated through each section for which it is required."
Not complicated. Looks good to me!
This pull request was briefly discussed at yesterday's Board meeting, but there was insufficient time prior to the meeting for Director's to give it proper consideration. The Board voted to hold this request open for another month and reconsider at the next Board meeting.
@ABISprotocol I will review and see if there are any changes I can suggest to help clarify.
@pmlaw As an aside, I will note that most of the Board members appear not to have read a private forum message sent to them by me summarizing the pull requests. (The forum messaging function allows me to see which Board members have logged in and read the summary, which was sent to all Board members on July 11, and which has also been received by Greg Egan as Elizabeth Ploshay forwarded it on to Greg). Gavin, Elizabeth, and Jon have read the message I sent on the subject (again, the forum has a function which tells me who has "read" the message or whether it remains unread by particular recipients). This doesn't mean that the Board members who haven't read their private messages on the forum haven't seen the summary, since it's my understanding that private messages sent to someone via that forum result in a copy of the message being sent to the e-mail of the recipient, as well, which is an automated part of the forum function. However, I recommend all Board members actually log in to the forum and check their messages, anyway.
@pmlaw When I hear back from the Board on what they have decided to do with what I've already submitted, whether they approve, deny, or approve in part with modification, then I'll come back to this matter.
The Board voted against this proposal. The vote was unanimous with all Board members attending. The Board felt that the proposal was too specific and inflexible, that it would be difficult to administer in some circumstances. Some of the Board felt that many of the ideas recommended in this proposal should be implemented in practice but not codified in the bylaws.
@pmlaw Thanks for posting the result of the Board vote. Did the Board adopt an alternative proposal to address the unresolved issue relating to the importance of making a public agenda prior to its meetings, and addressing issues relating to minutes, or suggest its own, modified proposal?
@pmlaw I am leaving this branch with unmerged commits (as shown here, closed with unmerged commits) in place, but I will happily clean it up (which means I will delete the branch with unmerged commits) after the following has occurred: 1) I would like a response to my question which was posted here on August 12 (see above comment,), and 2) I will need to see the results of the Board of Directors vote on the seperate matter of 'Anonymity and Funding' which I would hope will be posted under the open issue No. 19 as well as under the proposal which is responsive to that issue, #23 Thank you.
Transparency Proposal - Agendas - Posting