[Bitcoin-development] A critique of bitcoin open source community

[Bitcoin-development] A critique of bitcoin open source community

[Mitar]

Hi!

Interesting read:

http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign3.html


Mitar

-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

Re: [Bitcoin-development] A critique of bitcoin open source community

[Melvin Carvalho]

[-- Attachment #1: Type: text/plain, Size: 9620 bytes --]

On 19 October 2013 18:38, Mitar <mmitar@gmail.com> wrote:

> Hi!
>
> Interesting read:
>
>
> http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign3.html
>

Im sympathetic to some of the points, but it seems slightly harsh.  I do
agree that we're lucky to have the excellent leadership of Gavin, who I
think is a great role model.

Perhaps the bitcoin community is at a size where it may benefit from a
loose code of conduct.  The ubuntu code of conduct has been excellent in
this respect, in helping to grow that community:

http://www.ubuntu.com/about/about-ubuntu/conduct

[[

Ubuntu Code of Conduct v2.0
Community

Ubuntu is about showing humanity to one another: the word itself captures
the spirit of being human.

We want a productive, happy and agile community that can welcome new ideas
in a complex field, improve every process every year, and foster
collaboration between groups with very different needs, interests and
skills.

We gain strength from diversity, and actively seek participation from those
who enhance it. This code of conduct exists to ensure that diverse groups
collaborate to mutual advantage and enjoyment. We will challenge prejudice
that could jeopardise the participation of any person in the project.

The Code of Conduct governs how we behave in public or in private whenever
the project will be judged by our actions. We expect it to be honored by
everyone who represents the project officially or informally, claims
affiliation with the project, or participates directly.
We strive to:

Be considerate

Our work will be used by other people, and we in turn will depend on the
work of others. Any decision we take will affect users and colleagues, and
we should consider them when making decisions.

Be respectful

Disagreement is no excuse for poor manners. We work together to resolve
conflict, assume good intentions and do our best to act in an empathic
fashion. We don't allow frustration to turn into a personal attack. A
community where people feel uncomfortable or threatened is not a productive
one.

Take responsibility for our words and our actions

We can all make mistakes; when we do, we take responsibility for them. If
someone has been harmed or offended, we listen carefully and respectfully,
and work to right the wrong.

Be collaborative

What we produce is a complex whole made of many parts, it is the sum of
many dreams. Collaboration between teams that each have their own goal and
vision is essential; for the whole to be more than the sum of its parts,
each part must make an effort to understand the whole.

Collaboration reduces redundancy and improves the quality of our work.
Internally and externally, we celebrate good collaboration. Wherever
possible, we work closely with upstream projects and others in the free
software community to coordinate our efforts. We prefer to work
transparently and involve interested parties as early as possible.

Value decisiveness, clarity and consensus

Disagreements, social and technical, are normal, but we do not allow them
to persist and fester leaving others uncertain of the agreed direction.

We expect participants in the project to resolve disagreements
constructively. When they cannot, we escalate the matter to structures with
designated leaders to arbitrate and provide clarity and direction.

Ask for help when unsure

Nobody is expected to be perfect in this community. Asking questions early
avoids many problems later, so questions are encouraged, though they may be
directed to the appropriate forum. Those who are asked should be responsive
and helpful.

Step down considerately

When somebody leaves or disengages from the project, we ask that they do so
in a way that minimises disruption to the project. They should tell people
they are leaving and take the proper steps to ensure that others can pick
up where they left off.
Leadership, authority and responsibility

We all lead by example, in debate and in action. We encourage new
participants to feel empowered to lead, to take action, and to experiment
when they feel innovation could improve the project. Leadership can be
exercised by anyone simply by taking action, there is no need to wait for
recognition when the opportunity to lead presents itself.
Delegation from the top

Responsibility for the project starts with the "benevolent dictator", who
delegates specific responsibilities and the corresponding authority to a
series of teams, councils and individuals, starting with the Community
Council ("CC"). That Council or its delegated representative will arbitrate
in any dispute.

We are a meritocracy; we delegate decision making, governance and
leadership from senior bodies to the most able and engaged candidates.
Support for delegation is measured

Nominations to the boards and councils are at the discretion of the
Community Council, however the Community Council will seek the input of the
community before confirming appointments.

Leadership is not an award, right, or title; it is a privilege, a
responsibility and a mandate. A leader will only retain their authority as
long as they retain the support of those who delegated that authority to
them.
We value discussion, data and decisiveness

We gather opinions, data and commitments from concerned parties before
taking a decision. We expect leaders to help teams come to a decision in a
reasonable time, to seek guidance or be willing to take the decision
themselves when consensus is lacking, and to take responsibility for
implementation.

The poorest decision of all is no decision: clarity of direction has value
in itself. Sometimes all the data are not available, or consensus is
elusive. A decision must still be made. There is no guarantee of a perfect
decision every time - we prefer to err, learn, and err less in future than
to postpone action indefinitely.

We recognise that the project works better when we trust the teams closest
to a problem to make the decision for the project. If we learn of a
decision that we disagree with, we can engage the relevant team to find
common ground, and failing that, we have a governance structure that can
review the decision. Ultimately, if a decision has been taken by the people
responsible for it, and is supported by the project governance, it will
stand. None of us expects to agree with every decision, and we value highly
the willingness to stand by the project and help it deliver even on the
occasions when we ourselves may prefer a different route.
Open meritocracy

We invite anybody, from any company, to participate in any aspect of the
project. Our community is open, and any responsibility can be carried by
any contributor who demonstrates the required capacity and competence.
Teamwork

A leader's foremost goal is the success of the team.

"A virtuoso is judged by their actions; a leader is judged by the actions
of their team." A leader knows when to act and when to step back. They know
when to delegate work, and when to take it upon themselves.
Credit

A good leader does not seek the limelight, but celebrates team members for
the work they do. Leaders may be more visible than members of the team,
good ones use that visibility to highlight the great work of others.
Courage and considerateness

Leadership occasionally requires bold decisions that will not be widely
understood, consensual or popular. We value the courage to take such
decisions, because they enable the project as a whole to move forward
faster than we could if we required complete consensus. Nevertheless,
boldness demands considerateness; take bold decisions, but do so mindful of
the challenges they present for others, and work to soften the impact of
those decisions on them. Communicating changes and their reasoning clearly
and early on is as important as the implementation of the change itself.
Conflicts of interest

We expect leaders to be aware when they are conflicted due to employment or
other projects they are involved in, and abstain or delegate decisions that
may be seen to be self-interested. We expect that everyone who participates
in the project does so with the goal of making life better for its users.

When in doubt, ask for a second opinion. Perceived conflicts of interest
are important to address; as a leader, act to ensure that decisions are
credible even if they must occasionally be unpopular, difficult or
favourable to the interests of one group over another.

This Code is not exhaustive or complete. It is not a rulebook; it serves to
distill our common understanding of a collaborative, shared environment and
goals. We expect it to be followed in spirit as much as in the letter.

The Ubuntu Code of Conduct is licensed under the Creative Commons
Attribution-Share Alike 3.0 license. You may re-use it for your own
project, and modify it as you wish, just please allow others to use your
modifications and give credit to the Ubuntu Project!

]]


>
>
> Mitar
>
> --
> http://mitar.tnode.com/
> https://twitter.com/mitar_m
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 11137 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Gregory Maxwell]

On Sat, Oct 19, 2013 at 9:38 AM, Mitar <mmitar@gmail.com> wrote:
> Hi!
> Interesting read:
> http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign3.html

Hopefully Nick will show up someplace and offer some specific pointers
to where we failed him.

The only interaction I can find from him on IRC is in #bitcoin, rather
than #bitcoin-dev:

--- Day changed Mon Sep 16 2013
11:45 < csmpls> Hi, I'm interested in contributing to the official
bitcoin project. Is there a mailing list I can join?
11:46 < neo2> csmpls, contributing how?
11:47 < csmpls> neo2 - probably start by approaching a low priority
issue like this one https://github.com/bitcoin/bitcoin/issues/2545
11:48 < michagogo> csmpls: There *is* a mailing list
11:48 < michagogo> ;;google bitcoin-dev mailing list
11:48 <@gribble> SourceForge.net: Bitcoin: bitcoin-development:
<http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>;
Bitcoin-development Info
11:48 < csmpls> Great, thanks.
11:48 < michagogo> I don't know how active it is, though
11:49 < michagogo> There's also the #bitcoin-dev channel

I got involved with Bitcoin without previously interacting with other
contributors (AFAIK) and maybe things have changed in ways invisibly
to me. But I don't think so. Michagogo, who was answering there, is a
newer participant and I don't think anyone knows him from anywhere.
Certainly if things have become less welcome to new participants that
would be bad.

I can point out a number of other recent contributors who, as far as I
can tell, just showed up and stared contributing.  But I don't think
that the existence of exceptions is sufficiently strong evidence that
there isn't a problem.

The specific complaints I can extract from that article are:

"I wasn't even allowed to edit the wiki"

I'm confused about this, if he's referring to en.bitcoin.it.  Editing
it is open to anyone who is willing to pay the 0.01
(https://en.bitcoin.it/wiki/BitcoinPayment) anti-spam fee. This isn't
a policy set by the bitcoin development community, though I'm not sure
that its a terrible one. I've both paid it on behalf of other users
and made edits on behalf of people who didn't want to go to it.  At
least relative to some policy which requires actual approval the
payment antispam is at least open to anyone with Bitcoin.

"My IRC questions about issues on the github page were never answered"

Without a nick I'm unable to find more than the above, unfortunately.
So I don't yet know what we need to improve there.

"#bitcoin-dev would rather talk about conspiracies, or about
destroying other cryptocurrencies"

I've been pretty aggressive about punting out offtopic conversation
from #bitcoin-dev lately. Enough that I worried that my actions would
be the inspiration for this complaint. Much of the time discussion
like that is brought in and primarily continued by people who are not
active in the development community at all, but deflecting it to other
challenge without creating a hostile environment (or one that merely
feels hostile to new people) is hard.  Nicks comments themselves may
be a useful thing for me to show to people in the future on that
point.

"Bitcoiners are a bunch of paranoid, anti-authoritarian nutjobs"

I actually don't think that this stereotype accurately reflects the
development community. (In fact, I personally enjoy the great sport of
being called a statist by some of these aformentioned jutjobs, but
none of them are developers). On his other article Nick also asserts
"Most contributors hide their identities", but this is factually
untrue as far as I can tell. (In that same article he writes,
"Bitcoin's core code is written in Typescript, which is compiled into
C++"…)

"I looked at the many items sitting in pull request purgatory"

Many of the long standing pull requests are actually created by people
with direct commit access.  We use a model which has a relatively long
pipeline, a fact which I think is justified by the safety
criticialness of the software and our current shortages of active
review. Hopefully long term motion towards increased codebase
modularity will allow faster merging of "safe" changes.

But I suspect there will always be a backlog, at least of "unsafe" changes.

Which brings me to,

"I didn't even know what I had to do"

Above all, I think the most important takeaway from this is that we
need to have better introductory materials.

One obvious place to put them would be
http://bitcoin.org/en/development  but the IRC question makes me
believe that Nick hadn't actually found that page, it's a little
buried.

Re: [Bitcoin-development] A critique of bitcoin open source community

[Mitar]

Hi!

Gregory, thank you for your time and answers. Just maybe to clarify
where Nick is coming from, there are two previous articles:

http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign1.html
http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign2.html


Mitar

On Sat, Oct 19, 2013 at 1:40 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> On Sat, Oct 19, 2013 at 9:38 AM, Mitar <mmitar@gmail.com> wrote:
>> Hi!
>> Interesting read:
>> http://courses.ischool.berkeley.edu/i290m-ocpp/site/article/nmerrill-assign3.html
>
> Hopefully Nick will show up someplace and offer some specific pointers
> to where we failed him.
>
> The only interaction I can find from him on IRC is in #bitcoin, rather
> than #bitcoin-dev:
>
> --- Day changed Mon Sep 16 2013
> 11:45 < csmpls> Hi, I'm interested in contributing to the official
> bitcoin project. Is there a mailing list I can join?
> 11:46 < neo2> csmpls, contributing how?
> 11:47 < csmpls> neo2 - probably start by approaching a low priority
> issue like this one https://github.com/bitcoin/bitcoin/issues/2545
> 11:48 < michagogo> csmpls: There *is* a mailing list
> 11:48 < michagogo> ;;google bitcoin-dev mailing list
> 11:48 <@gribble> SourceForge.net: Bitcoin: bitcoin-development:
> <http://sourceforge.net/mailarchive/forum.php?forum_name=bitcoin-development>;
> Bitcoin-development Info
> 11:48 < csmpls> Great, thanks.
> 11:48 < michagogo> I don't know how active it is, though
> 11:49 < michagogo> There's also the #bitcoin-dev channel
>
> I got involved with Bitcoin without previously interacting with other
> contributors (AFAIK) and maybe things have changed in ways invisibly
> to me. But I don't think so. Michagogo, who was answering there, is a
> newer participant and I don't think anyone knows him from anywhere.
> Certainly if things have become less welcome to new participants that
> would be bad.
>
> I can point out a number of other recent contributors who, as far as I
> can tell, just showed up and stared contributing.  But I don't think
> that the existence of exceptions is sufficiently strong evidence that
> there isn't a problem.
>
> The specific complaints I can extract from that article are:
>
> "I wasn't even allowed to edit the wiki"
>
> I'm confused about this, if he's referring to en.bitcoin.it.  Editing
> it is open to anyone who is willing to pay the 0.01
> (https://en.bitcoin.it/wiki/BitcoinPayment) anti-spam fee. This isn't
> a policy set by the bitcoin development community, though I'm not sure
> that its a terrible one. I've both paid it on behalf of other users
> and made edits on behalf of people who didn't want to go to it.  At
> least relative to some policy which requires actual approval the
> payment antispam is at least open to anyone with Bitcoin.
>
> "My IRC questions about issues on the github page were never answered"
>
> Without a nick I'm unable to find more than the above, unfortunately.
> So I don't yet know what we need to improve there.
>
> "#bitcoin-dev would rather talk about conspiracies, or about
> destroying other cryptocurrencies"
>
> I've been pretty aggressive about punting out offtopic conversation
> from #bitcoin-dev lately. Enough that I worried that my actions would
> be the inspiration for this complaint. Much of the time discussion
> like that is brought in and primarily continued by people who are not
> active in the development community at all, but deflecting it to other
> challenge without creating a hostile environment (or one that merely
> feels hostile to new people) is hard.  Nicks comments themselves may
> be a useful thing for me to show to people in the future on that
> point.
>
> "Bitcoiners are a bunch of paranoid, anti-authoritarian nutjobs"
>
> I actually don't think that this stereotype accurately reflects the
> development community. (In fact, I personally enjoy the great sport of
> being called a statist by some of these aformentioned jutjobs, but
> none of them are developers). On his other article Nick also asserts
> "Most contributors hide their identities", but this is factually
> untrue as far as I can tell. (In that same article he writes,
> "Bitcoin's core code is written in Typescript, which is compiled into
> C++"…)
>
> "I looked at the many items sitting in pull request purgatory"
>
> Many of the long standing pull requests are actually created by people
> with direct commit access.  We use a model which has a relatively long
> pipeline, a fact which I think is justified by the safety
> criticialness of the software and our current shortages of active
> review. Hopefully long term motion towards increased codebase
> modularity will allow faster merging of "safe" changes.
>
> But I suspect there will always be a backlog, at least of "unsafe" changes.
>
> Which brings me to,
>
> "I didn't even know what I had to do"
>
> Above all, I think the most important takeaway from this is that we
> need to have better introductory materials.
>
> One obvious place to put them would be
> http://bitcoin.org/en/development  but the IRC question makes me
> believe that Nick hadn't actually found that page, it's a little
> buried.



-- 
http://mitar.tnode.com/
https://twitter.com/mitar_m

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

On 2013-10-19, at 1:40 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:
> 
> "I wasn't even allowed to edit the wiki"
> 
> I'm confused about this, if he's referring to en.bitcoin.it.  Editing
> it is open to anyone who is willing to pay the 0.01
> (https://en.bitcoin.it/wiki/BitcoinPayment) anti-spam fee. This isn't
> a policy set by the bitcoin development community, though I'm not sure
> that its a terrible one. I've both paid it on behalf of other users
> and made edits on behalf of people who didn't want to go to it.  At
> least relative to some policy which requires actual approval the
> payment antispam is at least open to anyone with Bitcoin.


I have a question regarding this part. I wrote a BIP for base 58 encoding / encryption of BIP 32 root keys. The BIP page states that we shouldn't add to this list ourselves, but should contact you for a BIP number. I have contacted you a couple times on bitcointalk for a BIP number, but haven't received a response (or do those requests explicitly have to go to your email address)? 

Proposal in question: https://bitcointalk.org/index.php?topic=258678.0


Cheers,

jp


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Luke-Jr]

On Saturday, October 19, 2013 9:16:24 PM Jean-Paul Kogelman wrote:
> I have a question regarding this part. I wrote a BIP for base 58 encoding /
> encryption of BIP 32 root keys. The BIP page states that we shouldn't add
> to this list ourselves, but should contact you for a BIP number. I have
> contacted you a couple times on bitcointalk for a BIP number, but haven't
> received a response (or do those requests explicitly have to go to your
> email address)?

See BIP 1 for the process.. proposals go to this mailing list first.

Luke

Re: [Bitcoin-development] A critique of bitcoin open source community

[Mike Hearn]

[-- Attachment #1: Type: text/plain, Size: 792 bytes --]

I was hoping to see something interesting and useful, but all I saw was
absurd ranting. Example quote:

It is not known where bitcoin contributors are based. Gavin Andersson, a
major contributor, is a well-known South African
anarchist/crypto-libertarian. Most contributors hide their identities.
I don't know who this guy is or why anyone should care what he thinks, but
I doubt any of us have time for someone who can't even be bothered spelling
Gavin's name correctly, thinks he is South African or would describe him as
an anarchist.

Open source development can be intimidating and brutal at times, it's
probably one factor that causes the massive gender skew. But many pages
have been written on that topic, here is probably not the right place to
thrash it out for the umpteenth time.

[-- Attachment #2: Type: text/html, Size: 967 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Gregory Maxwell]

On Sat, Oct 19, 2013 at 3:29 PM, Luke-Jr <luke@dashjr.org> wrote:
> See BIP 1 for the process.. proposals go to this mailing list first.

FWIW, he did post to the mailing list and he got an underwhelming response:

http://sourceforge.net/mailarchive/forum.php?thread_name=20ec1e35-3051-45d6-b449-e4a4d5c06dc8%40me.com&forum_name=bitcoin-development

When I responded to him on BCT I said "I was about to suggest you hit
the mailing list for some initial comments first— but I see you've
done that. I'll issue a number in a couple days once there has been a
little chance for some discussion.".

Since much discussion didn't materialize I went and gave it a
technical once over, posting to the forum.  In hindsight, I probably
should have also posted my review to the mailing list, which might
have served to restart some additional discussion.

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

[-- Attachment #1: Type: text/plain, Size: 698 bytes --]

I submitted the proposal to the mailing list on July 19, 2003.

 
On 2013-10-19, at 3:29 PM, Luke-Jr <luke@dashjr.org> wrote:

> On Saturday, October 19, 2013 9:16:24 PM Jean-Paul Kogelman wrote:
>> I have a question regarding this part. I wrote a BIP for base 58 encoding /
>> encryption of BIP 32 root keys. The BIP page states that we shouldn't add
>> to this list ourselves, but should contact you for a BIP number. I have
>> contacted you a couple times on bitcointalk for a BIP number, but haven't
>> received a response (or do those requests explicitly have to go to your
>> email address)?
> 
> See BIP 1 for the process.. proposals go to this mailing list first.
> 
> Luke

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

[-- Attachment #1: Type: text/plain, Size: 182 bytes --]


On 2013-10-19, at 4:21 PM, Jean-Paul Kogelman <jeanpaulkogelman@me.com> wrote:

> I submitted the proposal to the mailing list on July 19, 2003.

That would be 2013. sorry.


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

[-- Attachment #1: Type: text/plain, Size: 1135 bytes --]


On 2013-10-19, at 4:20 PM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> On Sat, Oct 19, 2013 at 3:29 PM, Luke-Jr <luke@dashjr.org> wrote:
>> See BIP 1 for the process.. proposals go to this mailing list first.
> 
> FWIW, he did post to the mailing list and he got an underwhelming response:
> 
> http://sourceforge.net/mailarchive/forum.php?thread_name=20ec1e35-3051-45d6-b449-e4a4d5c06dc8%40me.com&forum_name=bitcoin-development

Although I agree that the number of responses on the mailing list was minimal, they were overall positive. Mike voiced concerns about not having a date field to limit the rescan when importing, but other than that, most of the discussion was on bitcointalk. I've made a number of revisions, trying to incorporate the suggestions that were given. Obviously this doesn't mean that the draft is final (specifically the KDF's that can be used is still up for debate and having 29 undefined ID's means it's reasonably future proof).

Having it on the BIP page doesn't make it any more official, I agree, but it does increase its exposure and will hopefully spark some more discussion.


jp

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 2087 bytes --]

On Sat, Oct 19, 2013 at 04:35:13PM -0700, Jean-Paul Kogelman wrote:
> > On Sat, Oct 19, 2013 at 3:29 PM, Luke-Jr <luke@dashjr.org> wrote:
> >> See BIP 1 for the process.. proposals go to this mailing list first.
> > 
> > FWIW, he did post to the mailing list and he got an underwhelming response:
> > 
> > http://sourceforge.net/mailarchive/forum.php?thread_name=20ec1e35-3051-45d6-b449-e4a4d5c06dc8%40me.com&forum_name=bitcoin-development
> 
> Although I agree that the number of responses on the mailing list was minimal, they were overall positive. Mike voiced concerns about not having a date field to limit the rescan when importing, but other than that, most of the discussion was on bitcointalk. I've made a number of revisions, trying to incorporate the suggestions that were given. Obviously this doesn't mean that the draft is final (specifically the KDF's that can be used is still up for debate and having 29 undefined ID's means it's reasonably future proof).
> 
> Having it on the BIP page doesn't make it any more official, I agree, but it does increase its exposure and will hopefully spark some more discussion.

Having it on the BIP page *does* make it more official, at least the way
we've been using the BIP page, which is to filter out the proposals that
haven't gotten much support at all. (or maybe are just controversial)

FWIW I myself haven't pushed hard for getting an "official" BIP number
for my draft NODE_BLOOM BIP, even though I've got support from most of
the dev team on the pull-request:
https://github.com/bitcoin/bitcoin/pull/2900 I'm probably at the point
where I could get one assigned - Litecoin for instance has made that
change - but really I just see that as a formality; that it's still a
controversial idea is much more relevant.

In any case I don't see any working code in your email, I'd suggest
writing some. You're BIP would be much more likely to be accepted if you
were more involved in wallet development.

-- 
'peter'[:-1]@petertodd.org
000000000000000ad5e0cbc9438203b9cf2dcae776774f59575e38fcefa802ed

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

[-- Attachment #1: Type: text/plain, Size: 2269 bytes --]


>> Having it on the BIP page doesn't make it any more official, I agree, but it does increase its exposure and will hopefully spark some more discussion.
> 
> Having it on the BIP page *does* make it more official, at least the way
> we've been using the BIP page, which is to filter out the proposals that
> haven't gotten much support at all. (or maybe are just controversial)

Interesting. The main reason I wrote my proposal was because the only proposal that came close to covering the same area was BIP 39, which at that time had 2 paragraphs of text (although admittedly did link to a text file off site where the draft was being developed). And currently there are 2 proposals that have numbers allocated but are empty (BIP 40 and 41) with no references to the development or discussion.

I appreciate the fact that acceptance of proposals on the BIP page are more strict, but it may be desirable to have the enforcement be more uniform. Also, BIP 38 is gaining more acceptance out in the community (many sites support the import of these keys and a growing number of paper wallet sites / coin / card vendors are offering it as an option), yet it's still missing from the BIP list, which seems to me a bit counter to the arguments given about community acceptance.

> FWIW I myself haven't pushed hard for getting an "official" BIP number
> for my draft NODE_BLOOM BIP, even though I've got support from most of
> the dev team on the pull-request:
> https://github.com/bitcoin/bitcoin/pull/2900 I'm probably at the point
> where I could get one assigned - Litecoin for instance has made that
> change - but really I just see that as a formality; that it's still a
> controversial idea is much more relevant.


> In any case I don't see any working code in your email, I'd suggest
> writing some. You're BIP would be much more likely to be accepted if you
> were more involved in wallet development.

Good point. I'm developing my own client (which has the code up and running, with unit tests), but I'm not ready to release it just yet until I've got all the client's alpha features working. Would putting contact information there so people can ask for the relevant code be sufficient until I have my client up on github?


jp



[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Wladimir]

[-- Attachment #1: Type: text/plain, Size: 1039 bytes --]

On Sun, Oct 20, 2013 at 1:20 AM, Gregory Maxwell <gmaxwell@gmail.com> wrote:

> Since much discussion didn't materialize I went and gave it a
> technical once over, posting to the forum.


At least I now understand where he got the idea of bitcoin devs being a
bunch of paranoid, anti-authoritarian nutjobs :-) I've been on a lot of
forums in my life but never encountered one with such selfish, unhelpful,
trolling, complaining sods (well maybe apart from 15-year old gamers).

Nick couldn't have got that idea from discussion on this mailing list or
#bitcoin-dev. Please don't send anyone to that jungle. People shouldn't get
the idea that that the forum is our development community, or even endorsed
by the devs.

As for the real developer community, I haven't noticed so much
unfriendliness or closedness. But the core devs are with very few people
(certainly compared to the number of users) and reviewing and testing takes
time so pull requests, proposals and such can linger for a while. Which can
indeed be frustrating.

Wladimir

[-- Attachment #2: Type: text/html, Size: 1710 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 3039 bytes --]

On Sat, Oct 19, 2013 at 05:52:49PM -0700, Jean-Paul Kogelman wrote:
> Interesting. The main reason I wrote my proposal was because the only proposal that came close to covering the same area was BIP 39, which at that time had 2 paragraphs of text (although admittedly did link to a text file off site where the draft was being developed). And currently there are 2 proposals that have numbers allocated but are empty (BIP 40 and 41) with no references to the development or discussion.
> 
> I appreciate the fact that acceptance of proposals on the BIP page are more strict, but it may be desirable to have the enforcement be more uniform. Also, BIP 38 is gaining more acceptance out in the community (many sites support the import of these keys and a growing number of paper wallet sites / coin / card vendors are offering it as an option), yet it's still missing from the BIP list, which seems to me a bit counter to the arguments given about community acceptance.

No, that just means the authors of BIP 38 know community acceptance is
the most important thing; BIP numbers are secondary.

FWIW I think that BIP's should have been done as a github repository,
allowing for dealing with this stuff transparently as a pull-request.
It'd also be useful to handle BIP's that way to make it easy to archive
them, update them, and keep a log of what and why they were updated.
Just put them in markdown format, which is pretty much feature
equivalent to the wiki now that markdown supports images.

> > FWIW I myself haven't pushed hard for getting an "official" BIP number
> > for my draft NODE_BLOOM BIP, even though I've got support from most of
> > the dev team on the pull-request:
> > https://github.com/bitcoin/bitcoin/pull/2900 I'm probably at the point
> > where I could get one assigned - Litecoin for instance has made that
> > change - but really I just see that as a formality; that it's still a
> > controversial idea is much more relevant.
> 
> 
> > In any case I don't see any working code in your email, I'd suggest
> > writing some. You're BIP would be much more likely to be accepted if you
> > were more involved in wallet development.
> 
> Good point. I'm developing my own client (which has the code up and running, with unit tests), but I'm not ready to release it just yet until I've got all the client's alpha features working. Would putting contact information there so people can ask for the relevant code be sufficient until I have my client up on github?

No, just put the client up on github. If you think actually using it is
dangerous, just delibrately make it hard to use for people who shouldn't
be using it. Leave out compilation documentation for instance, or make
it check that it's on testnet first and refuse to run if it isn't.

Pond for instance doesn't make binaries available:
https://pond.imperialviolet.org/ IIRC only recently have they provided a
makefile.

-- 
'peter'[:-1]@petertodd.org
000000000000000b647feda1820ad95b2ea9efb742e9087b022bd3d37530dc06

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1155 bytes --]

On Sun, Oct 20, 2013 at 06:43:16PM -0400, Peter Todd wrote:
> FWIW I think that BIP's should have been done as a github repository,
> allowing for dealing with this stuff transparently as a pull-request.
> It'd also be useful to handle BIP's that way to make it easy to archive
> them, update them, and keep a log of what and why they were updated.
> Just put them in markdown format, which is pretty much feature
> equivalent to the wiki now that markdown supports images.

Figures, I'm told that's exactly how they were first done -
https://github.com/genjix/bips - only people found it inconvenient and
used the wiki instead.

Pathetic IMO for standards, but it wouldn't exactly be the first time
I've seen strong resistance to using revision control. (I quite
literally work with rocket scientists/satellite engineers who can't be
convinced to use it)

I dunno, maybe something using git submodules or subtrees - letting the
individual BIP "owners" make changes frequently until they're happy -
might have more social acceptance.

-- 
'peter'[:-1]@petertodd.org
000000000000000aff52788645172e4acca1d9fc9387ebe4074d9ce275273b44

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jeff Garzik]

On Sun, Oct 20, 2013 at 6:43 PM, Peter Todd <pete@petertodd.org> wrote:
> FWIW I think that BIP's should have been done as a github repository,
> allowing for dealing with this stuff transparently as a pull-request.
> It'd also be useful to handle BIP's that way to make it easy to archive
> them, update them, and keep a log of what and why they were updated.
> Just put them in markdown format, which is pretty much feature
> equivalent to the wiki now that markdown supports images.

Agreed -- let's do it.  I nominate you to do the conversion, and we'll
put it up at github.com/bitcoin/bips.git.

-- 
Jeff Garzik
Senior Software Engineer and open source evangelist
BitPay, Inc.      https://bitpay.com/

Re: [Bitcoin-development] A critique of bitcoin open source community

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 1453 bytes --]

On Sun, Oct 20, 2013 at 08:27:47PM -0400, Jeff Garzik wrote:
> On Sun, Oct 20, 2013 at 6:43 PM, Peter Todd <pete@petertodd.org> wrote:
> > FWIW I think that BIP's should have been done as a github repository,
> > allowing for dealing with this stuff transparently as a pull-request.
> > It'd also be useful to handle BIP's that way to make it easy to archive
> > them, update them, and keep a log of what and why they were updated.
> > Just put them in markdown format, which is pretty much feature
> > equivalent to the wiki now that markdown supports images.
> 
> Agreed -- let's do it.  I nominate you to do the conversion, and we'll
> put it up at github.com/bitcoin/bips.git.

Done: https://github.com/petertodd/bips/

GitHub supports MediaWiki these days, so just directly copying from
'View Source' in the bitcoin.it wiki worked pretty well; I archived the
exact text of BIP. Tables, images and math is all supported by github
and look fine, although github doesn't seem to support coloration in
tables. Users wishing to edit their pull-req's or create new ones can do
so easily by forking the repository - they can see their changes as they
go in GitHub.

I've probably missed some stuff re: formatting, and I haven't changed
any of the submission guideline text in bip 1 yet, but that's probably
90% of the work done.

-- 
'peter'[:-1]@petertodd.org
000000000000000245a735ccc14b98552e152f773c07efa2e89dd7f0463f61cf

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

[-- Attachment #1: Type: text/plain, Size: 1689 bytes --]


I was wondering, would it be possible to create an area where proposals like your NODE_BLOOM and BIP 38 could live? 

On 2013-10-20, at 11:25 PM, Peter Todd <pete@petertodd.org> wrote:

> On Sun, Oct 20, 2013 at 08:27:47PM -0400, Jeff Garzik wrote:
>> On Sun, Oct 20, 2013 at 6:43 PM, Peter Todd <pete@petertodd.org> wrote:
>>> FWIW I think that BIP's should have been done as a github repository,
>>> allowing for dealing with this stuff transparently as a pull-request.
>>> It'd also be useful to handle BIP's that way to make it easy to archive
>>> them, update them, and keep a log of what and why they were updated.
>>> Just put them in markdown format, which is pretty much feature
>>> equivalent to the wiki now that markdown supports images.
>> 
>> Agreed -- let's do it.  I nominate you to do the conversion, and we'll
>> put it up at github.com/bitcoin/bips.git.
> 
> Done: https://github.com/petertodd/bips/
> 
> GitHub supports MediaWiki these days, so just directly copying from
> 'View Source' in the bitcoin.it wiki worked pretty well; I archived the
> exact text of BIP. Tables, images and math is all supported by github
> and look fine, although github doesn't seem to support coloration in
> tables. Users wishing to edit their pull-req's or create new ones can do
> so easily by forking the repository - they can see their changes as they
> go in GitHub.
> 
> I've probably missed some stuff re: formatting, and I haven't changed
> any of the submission guideline text in bip 1 yet, but that's probably
> 90% of the work done.
> 
> -- 
> 'peter'[:-1]@petertodd.org
> 000000000000000245a735ccc14b98552e152f773c07efa2e89dd7f0463f61cf


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Peter Todd]

[-- Attachment #1: Type: text/plain, Size: 513 bytes --]

On Sun, Oct 20, 2013 at 11:40:26PM -0700, Jean-Paul Kogelman wrote:
> 
> I was wondering, would it be possible to create an area where proposals like your NODE_BLOOM and BIP 38 could live? 

Sure, I think Jeff mentioned the idea of a specific drafts/ directory
within the repository. (could also do a rejected/)

Less of an issue in some ways when it's all in git - just point people
to your bips fork.

-- 
'peter'[:-1]@petertodd.org
00000000000000099eaa116fac83a2b0e097cae3391c794990e128c8e162d91a

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 685 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

[-- Attachment #1: Type: text/plain, Size: 862 bytes --]

How about putting them into sub directories that map onto the status of the BIP? 

Reading BIP 1, that would make: 

Accepted
Active
Draft
Deferred
Final
Rejected
Replaced
Withdrawn

Would that place NODE_BLOOM and BIP 38 in Deferred?


On 2013-10-20, at 11:43 PM, Peter Todd <pete@petertodd.org> wrote:

> On Sun, Oct 20, 2013 at 11:40:26PM -0700, Jean-Paul Kogelman wrote:
>> 
>> I was wondering, would it be possible to create an area where proposals like your NODE_BLOOM and BIP 38 could live? 
> 
> Sure, I think Jeff mentioned the idea of a specific drafts/ directory
> within the repository. (could also do a rejected/)
> 
> Less of an issue in some ways when it's all in git - just point people
> to your bips fork.
> 
> -- 
> 'peter'[:-1]@petertodd.org
> 00000000000000099eaa116fac83a2b0e097cae3391c794990e128c8e162d91a


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Martin Sustrik]

On 21/10/13 08:52, Jean-Paul Kogelman wrote:
> How about putting them into sub directories that map onto the status of the BIP?
>
> Reading BIP 1, that would make:
>
> Accepted
> Active
> Draft
> Deferred
> Final
> Rejected
> Replaced
> Withdrawn

Have it been considered to do this via IETF? The process there is 
hardened by 40 years of experience and 7000+ RFCs. Probably better than 
anything you can devise yourself.

Martin

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

[-- Attachment #1: Type: text/plain, Size: 575 bytes --]

The list comes from BIP 1.

On 2013-10-21, at 12:03 AM, Martin Sustrik <sustrik@250bpm.com> wrote:

> On 21/10/13 08:52, Jean-Paul Kogelman wrote:
>> How about putting them into sub directories that map onto the status of the BIP?
>> 
>> Reading BIP 1, that would make:
>> 
>> Accepted
>> Active
>> Draft
>> Deferred
>> Final
>> Rejected
>> Replaced
>> Withdrawn
> 
> Have it been considered to do this via IETF? The process there is hardened by 40 years of experience and 7000+ RFCs. Probably better than anything you can devise yourself.
> 
> Martin


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Martin Sustrik]

On 21/10/13 09:07, Jean-Paul Kogelman wrote:
> The list comes from BIP 1.

Sorry, I haven't meant you personally. It was just a generic question 
about using existing process instead of inventing a new one on the go.

>> Have it been considered to do this via IETF? The process there is hardened by 40 years of experience and 7000+ RFCs. Probably better than anything you can devise yourself.
>>
>> Martin
>

Re: [Bitcoin-development] A critique of bitcoin open source community

[Melvin Carvalho]

[-- Attachment #1: Type: text/plain, Size: 2162 bytes --]

On 21 October 2013 09:03, Martin Sustrik <sustrik@250bpm.com> wrote:

> On 21/10/13 08:52, Jean-Paul Kogelman wrote:
> > How about putting them into sub directories that map onto the status of
> the BIP?
> >
> > Reading BIP 1, that would make:
> >
> > Accepted
> > Active
> > Draft
> > Deferred
> > Final
> > Rejected
> > Replaced
> > Withdrawn
>
> Have it been considered to do this via IETF? The process there is
> hardened by 40 years of experience and 7000+ RFCs. Probably better than
> anything you can devise yourself.
>

IETF is great for some things.  I think the bitcoin URI scheme is being
registered with them.

However the process can take many years to get to an RFC, for something
relatively simple, not to mention there can be costs too

Given that crypto currencies are a relatively new field, I am unsure the
IETF has a wealth of expertise in this area, compared with the core devs

Maybe IETF is better to standardize some of the communications or
serialization components, but not so much the BIPs.  Or perhaps some of the
BIPs can be written up as "Informational" rather than "Proposed Standard"
in the RFC format, and reviewed

I've followed quite a few FLOSS projects over the years.  Overall, I've
been amazingly impressed with the BIP process (dont forget it's used in
other systems too -- python?).  It seems an agile process, that strikes an
great balance between needed features, and documentation.  I think that's
exactly what will continue bitcoin's momentum in the short to medium term.


>
> Martin
>
>
> ------------------------------------------------------------------------------
> October Webinars: Code for Performance
> Free Intel webinars can help you accelerate application performance.
> Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
> from
> the latest Intel processors and coprocessors. See abstracts and register >
> http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

[-- Attachment #2: Type: text/html, Size: 3244 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Arto Bendiken]

On Mon, Oct 21, 2013 at 11:36 AM, Melvin Carvalho
<melvincarvalho@gmail.com> wrote:
>
> I've followed quite a few FLOSS projects over the years.  Overall, I've been
> amazingly impressed with the BIP process (dont forget it's used in other
> systems too -- python?).  It seems an agile process, that strikes an great
> balance between needed features, and documentation.  I think that's exactly
> what will continue bitcoin's momentum in the short to medium term.

Indeed. The BIP analogs that immediately come to mind would be the
enhancement proposal processes for Python, XMPP, and BitTorrent:

http://www.python.org/dev/peps/
http://xmpp.org/xmpp-protocols/xmpp-extensions/
http://www.bittorrent.org/beps/bep_0000.html

-- 
Arto Bendiken | @bendiken | http://ar.to

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jean-Paul Kogelman]

[-- Attachment #1.1: Type: text/plain, Size: 431 bytes --]


On 2013-10-21, at 2:44 AM, Arto Bendiken <arto@bendiken.net> wrote:

> 
> Indeed. The BIP analogs that immediately come to mind would be the
> enhancement proposal processes for Python, XMPP, and BitTorrent:

Bitcoin's BIP process is directly based off of Python's PEP process. 

Quote from BIP 1, History:

This document was derived heavily from Python's PEP-0001. In many places text was simply copied and modified.

[-- Attachment #1.2: Type: text/html, Size: 953 bytes --]

[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

Re: [Bitcoin-development] A critique of bitcoin open source community

[Jorge Timón]

I think it's great to move BIPs to github.
I also agree with the states -> directories mapping.
Git manages moved files well.


On 10/21/13, Jean-Paul Kogelman <jeanpaulkogelman@me.com> wrote:
>
> On 2013-10-21, at 2:44 AM, Arto Bendiken <arto@bendiken.net> wrote:
>
>>
>> Indeed. The BIP analogs that immediately come to mind would be the
>> enhancement proposal processes for Python, XMPP, and BitTorrent:
>
> Bitcoin's BIP process is directly based off of Python's PEP process.
>
> Quote from BIP 1, History:
>
> This document was derived heavily from Python's PEP-0001. In many places
> text was simply copied and modified.
>


-- 
Jorge Timón

http://freico.in/