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

[Jean-Paul Kogelman]

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




signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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

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

[Peter Todd]

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  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
000ad5e0cbc9438203b9cf2dcae776774f59575e38fcefa802ed


signature.asc
Description: Digital signature
--
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

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

[Jean-Paul Kogelman]

On 2013-10-19, at 4:20 PM, Gregory Maxwell  wrote:

> On Sat, Oct 19, 2013 at 3:29 PM, Luke-Jr  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


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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

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

[Jean-Paul Kogelman]

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

 
On 2013-10-19, at 3:29 PM, Luke-Jr  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


signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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

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

[Jean-Paul Kogelman]

On 2013-10-19, at 4:21 PM, Jean-Paul Kogelman  wrote:

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

That would be 2013. sorry.



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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

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

[Gregory Maxwell]

On Sat, Oct 19, 2013 at 3:29 PM, Luke-Jr  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.

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

[Bitcoin-development] Root key encoding / BIP process Was: A critique of bitcoin open source community

[Gregory Maxwell]

On Sat, Oct 19, 2013 at 2:16 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)?
>
> Proposal in question: https://bitcointalk.org/index.php?topic=258678.0

I responded to you in PM on July 19, 2013, 05:57:15 PM.

Then I followed up with a technical review after I didn't see much
other technical review happening:

https://bitcointalk.org/index.php?topic=258678.msg3128364#msg3128364

Which you responded to, correcting a few of my misunderstandings and
offering to make changes to the specification to make it more clear
and to correct a few of the limitations I pointed out.

At that point I put aside further action on your proposal waiting for
you to make those updates.

The reason to go through a serialization point for BIP numbers is to
avoid assigning them to things to people's pet ideas that haven't been
reviewed by or represent any identifiable part of the Bitcoin
community. (After all: You're free to publish any specs at all on your
own without a BIP. BIPs are not "official" but they should be stronger
than "some guy says this" if they are to mean anything).  I don't
generally see my role in this process as acting as an approver, but
rather just someone recognizing approval that already exists.

Generally I try not to assign numbers to things before I see evidence
of discussion which I can reasonably expect to result in an "community
outcome".  In some cases this means that I'll take up the role of
going through and being a second set of eyes on the document myself
(directly contributing to creating some community approval), as I did
in this case.

On October 2nd, you followed up with
https://bitcointalk.org/index.php?topic=258678.msg3287415#msg3287415
indicating that you'd made the changes addressing my points.

My apologies, I missed this completely as I not working on Bitcoin
things pretty much at all during 09/26 to 10/13 due to other
obligations. Thanks for your patience. Following up here was
absolutely the right thing to do if I'm dropping the ball.

Pieter, do you have any opinions to offer on this?  (Also, generally
to the list. I'm singling out Pieter only because just asking "anyone"
to comment tends to be less effective.)

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

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

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

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

[Mike Hearn]

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

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

[Jean-Paul Kogelman]

On 2013-10-19, at 1:40 PM, Gregory Maxwell  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



signature.asc
Description: Message signed with OpenPGP using GPGMail
--
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

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  wrote:
> On Sat, Oct 19, 2013 at 9:38 AM, Mitar  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:
> ;
> 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://bitco

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

[Gregory Maxwell]

On Sat, Oct 19, 2013 at 9:38 AM, Mitar  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:
;
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.

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

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

[Melvin Carvalho]

On 19 October 2013 18:38, Mitar  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,

[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

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

Re: [Bitcoin-development] BIP39 word list

[Pavol Rusnak]

On 19/10/13 01:58, Gregory Maxwell wrote:
> https://people.xiph.org/~greg/wordlist.visual.py

>> I've included the search utility I used below.

Yeah, there are lots of tools on the Internet. Posting links to them is
not helping. Sending pull requests with particular changesets with
explanation is. Well, or rather was. I think we are past the point where
it was wise to introduce changes to the word list ... (especially when
50 people have 51 different opinions on this topic)

-- 
Best Regards / S pozdravom,

Pavol Rusnak 

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