BIP process

BIP process
2011-10-18 21:26 ` Nils Schneider
  2011-10-20  5:02 ` Alex Waters
  
From: Gavin Andresen @ 2011-10-18 19:17 UTC (permalink / raw)
  To: Bitcoin Dev

Amir started the "get more formal about changes to bitcoin" ball
rolling by creating BIP 0001, starting from the Python "PEP" /
BitTorrent "BEP" processes:
  https://en.bitcoin.it/w/index.php?title=BIP_0001

The idea is to use BIPs for changes that may or will affect every
bitcoin implementation (not to use them for proposed changes to one
particular implementation).

I'd like to propose some minor changes to the process:

• I propose that BIPs be wiki pages, with a social convention that the
Author gets final word if any editing wars break out.

• If he's willing, I propose that Amir take the role of BIP editor.

• I think bitcoin is still too small to have a specialized
"bitcoin-ideas" mailing list; I propose that new potential BIPs be
discussed either here or on the bitcoin-dev mailing list.

What do y'all think?

-- 
--
Gavin Andresen



 permalink raw reply	[|nested]
2011-10-18 19:17 Gavin Andresen

  2011-10-20  5:02 ` Alex Waters
  
From: Nils Schneider @ 2011-10-18 21:26 UTC (permalink / raw)
  To: bitcoin-development


> • I propose that BIPs be wiki pages, with a social convention that the
> Author gets final word if any editing wars break out.

That's a good idea. What about using GitHub's Wiki feature for BIPs?
They support MarkDown which is easy to read in text editors so we could
someday create a repo with all finalized BIPs. That's a lot easier than
importing a mediawiki dump. The last time en.bitcoin.it went down I
tried to setup a static mirror and that was nearly impossible without a
full LAMP stack. Also, BIPs should only contain images when absolutely
necessary.

> • If he's willing, I propose that Amir take the role of BIP editor.

ack

> • I think bitcoin is still too small to have a specialized
> "bitcoin-ideas" mailing list; I propose that new potential BIPs be
> discussed either here or on the bitcoin-dev mailing list.

ack



 permalink raw reply	[|nested]
2011-10-18 19:17 Gavin Andresen
  2011-10-18 21:26 ` Nils Schneider

  2011-10-20 11:27   ` Christian Decker
  
From: Alex Waters @ 2011-10-20  5:02 UTC (permalink / raw)
  To: Bitcoin Dev

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

>
>
> • I propose that BIPs be wiki pages, with a social convention that the
> Author gets final word if any editing wars break out.


ACK

>

• If he's willing, I propose that Amir take the role of BIP editor.
>
> ACK


> • I think bitcoin is still too small to have a specialized
> "bitcoin-ideas" mailing list; I propose that new potential BIPs be
> discussed either here or on the bitcoin-dev mailing list.
>

ACK

As for what Nils mentioned on using GitHub's Wiki feature, Gavin seems to
have started a few proposals at
https://github.com/gavinandresen/bitcoin-git/wiki. I think this is the right
direction to head in, and a composite list of similar proposals could be
maintained on their own repository (to maintain separation from the core
Bitcoin repo.)

-Alex

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

 permalink raw reply	[|nested]
2011-10-20  5:02 ` Alex Waters

  
From: Christian Decker @ 2011-10-20 11:27 UTC (permalink / raw)
  To: Alex Waters;  Bitcoin Dev

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

On Thu, Oct 20, 2011 at 7:02 AM, Alex Waters <ampedal@gmail•com> wrote:

>
>> • I propose that BIPs be wiki pages, with a social convention that the
>> Author gets final word if any editing wars break out.
>
>
> ACK
>
Does it have to be wiki pages if we're going through an editorial process
anyway, and there will be few who can actually edit the pages directly? I'd
go for simple HTML documents in a repository.

>
>
> • If he's willing, I propose that Amir take the role of BIP editor.
>>
>> ACK
>
ACK

>
>
>> • I think bitcoin is still too small to have a specialized
>> "bitcoin-ideas" mailing list; I propose that new potential BIPs be
>> discussed either here or on the bitcoin-dev mailing list.
>>
>
> ACK
>
Definitely. I don't think too many requests will come right away, and by
posting them here we make sure that the most knowledgeable people are there
to check and improve what might eventually end up in the clients.

>
> As for what Nils mentioned on using GitHub's Wiki feature, Gavin seems to
> have started a few proposals at
> https://github.com/gavinandresen/bitcoin-git/wiki. I think this is the
> right direction to head in, and a composite list of similar proposals could
> be maintained on their own repository (to maintain separation from the core
> Bitcoin repo.)
>
> -Alex
>
>
> ------------------------------------------------------------------------------
> The demand for IT networking professionals continues to grow, and the
> demand for specialized networking skills is growing even more rapidly.
> Take a complimentary Learning@Ciosco Self-Assessment and learn
> about Cisco certifications, training, and career opportunities.
> http://p.sf.net/sfu/cisco-dev2dev
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>

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

 permalink raw reply	[|nested]
2014-10-15  9:22 ` Gregory Maxwell
                   ` (2 more replies)
  
From: Wladimir @ 2014-10-15  8:29 UTC (permalink / raw)
  To: Bitcoin Dev, Gregory Maxwell, Amir Taaki

Hello,

I'm trying to create a bit of process around the
https://github.com/bitcoin/bips repository.

A) Currently a lot of pulls are open for various BIPs and it is not
clear who should comment on them, or who decides on changes to be
merged.

Currently all BIP changes have to go through the Bitcoin Core team,
which is a narrow bottleneck and makes little sense when you think
about it. But I don't want to go back to the wiki state in which
everyone can make arbitrary changes to any BIP - we need to distribute
the process somehow.

I'd like to propose to make the author (or someone they delegate to)
the primary contact for each BIP. They should comment on changes, and
either accept or reject them. If they accept them, the change will be
merged.

Of course this means that there is a responsibility for the author to
adhere to BIP 1. For example if your BIP is final, don't allow any
technical changes. To do small clarifications, spelling or adding
implementations or examples is OK, but changing or adding to a
protocol is not - this needs a new BIP. Changing your BIP status
without community consensus is also not OK.

B) I also think it makes sense to move the BIP discussion (both about
the BIP process and individual BIPs) to a separate mailing list.

bitcoin-development currently has a dual function: discussion of
Bitcoin Core implementation concerns, as well as global changes to
Bitcoin (in the form of BIPs).

This makes the list too busy for some people, but it is critical that
everyone writing a Bitcoin node or client is up-to-date with proposals
and can comment on them.

Wladimir



 permalink raw reply	[|nested]
2014-10-15  9:22 ` 
                   ` 
  
From: Wladimir @ 2014-10-15  8:29 UTC (permalink / raw)
  To: Bitcoin Dev, Gregory Maxwell, Amir Taaki

Hello,

I'm trying to create a bit of process around the
https://github.com/bitcoin/bips repository.

A) Currently a lot of pulls are open for various BIPs and it is not
clear who should comment on them, or who decides on changes to be
merged.

Currently all BIP changes have to go through the Bitcoin Core team,
which is a narrow bottleneck and makes little sense when you think
about it. But I don't want to go back to the wiki state in which
everyone can make arbitrary changes to any BIP - we need to distribute
the process somehow.

I'd like to propose to make the author (or someone they delegate to)
the primary contact for each BIP. They should comment on changes, and
either accept or reject them. If they accept them, the change will be
merged.

Of course this means that there is a responsibility for the author to
adhere to BIP 1. For example if your BIP is final, don't allow any
technical changes. To do small clarifications, spelling or adding
implementations or examples is OK, but changing or adding to a
protocol is not - this needs a new BIP. Changing your BIP status
without community consensus is also not OK.

B) I also think it makes sense to move the BIP discussion (both about
the BIP process and individual BIPs) to a separate mailing list.

bitcoin-development currently has a dual function: discussion of
Bitcoin Core implementation concerns, as well as global changes to
Bitcoin (in the form of BIPs).

This makes the list too busy for some people, but it is critical that
everyone writing a Bitcoin node or client is up-to-date with proposals
and can comment on them.

Wladimir



 permalink raw reply	[|nested]
2014-10-15  9:22 ` Gregory Maxwell

  2014-10-15 18:58     ` Cory Fields
  2014-10-16  7:50     ` Thomas Zander
  
From: Wladimir @ 2014-10-15  9:36 UTC (permalink / raw)
  To: Gregory Maxwell;  Bitcoin Dev, Amir Taaki

> This all makes a lot of sense to me, and would help a lot with the
> workflow.  Unfortunately github pulls and issues really have nothing
> to faciltate a multistage workflow... e.g. where something can go
> through several steps.

Indeed, pull requests don't have a "status".
It would be possible to (ab)use labels for this.

The drawback of labels is that only the repository team can set these,
there is no way to delegate. But I suppose it'd be possible to build
something on top of the github API that handles this.

> We're also having problems with people failing to comment on things,
> not even "I looked at this and have no opinion", which is really
> obstructing things.

Well - the only way to avoid that is to set a reasonable deadline,
after which there is a default decision. You'd hope this would
motivate people to get involved in time.

Wladimir



 permalink raw reply	[|nested]
2014-10-15  8:29 [Bitcoin-development] BIP process Wladimir
  2014-10-15  9:22 ` Gregory Maxwell

  2014-10-15 15:46   ` Mike Hearn
  2014-10-19  7:17 ` xor
  
From: Gavin Andresen @ 2014-10-15 15:37 UTC (permalink / raw)
  To: Wladimir;  Bitcoin Dev, Amir Taaki

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

RE: process:

I like author == primary control, and an "assume they will do the right
thing, revert if they don't"

RE: separate mailing list for BIP discussion:

Great idea. Jeff Garzik was looking for a better mailing list solution than
SourceForge, but assuming
there isn't a clearly better solution I think "we" should create a strictly
moderated bitcoin-bips@lists•sourceforge list.

-- 
--
Gavin Andresen

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

 permalink raw reply	[|nested]
2014-10-15 15:37 ` Gavin Andresen

  2014-10-15 15:54     ` Adam Back
  
From: Mike Hearn @ 2014-10-15 15:46 UTC (permalink / raw)
  To: Gavin Andresen;  Bitcoin Dev

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

>
> Great idea. Jeff Garzik was looking for a better mailing list solution
> than SourceForge, but assuming
> there isn't a clearly better solution I think "we" should create a
> strictly moderated bitcoin-bips@lists•sourceforge list.
>

Let's stay away from SF.net or any mailman-controlled lists if at all
possible. They break DKIM signatures which means they're no longer
compatible with Yahoo, all mail from Yahoo users gets spamfoldered
immediately. Google Groups gets this right. Perhaps other list operators do
too. Groups also has moderation features.

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

 permalink raw reply	[|nested]
2014-10-15 15:46   ` Mike Hearn

  2014-10-15 16:47       ` Peter Todd
                         ` (2 more replies)
  
From: Adam Back @ 2014-10-15 15:54 UTC (permalink / raw)
  To: Mike Hearn;  Bitcoin Dev

please not google groups *, I'd vote for sourceforge or other simple
open list software over google groups.

Adam

* Google lists are somehow a little proprietary or gmail lockin
focused eg it makes things extra hard to subscribe with a non-google
address if google has any hint that your address is associated with a
gmail account.  Quite frustrating.

On 15 October 2014 16:46, Mike Hearn <mike@plan99•net> wrote:
>> Great idea. Jeff Garzik was looking for a better mailing list solution
>> than SourceForge, but assuming
>> there isn't a clearly better solution I think "we" should create a
>> strictly moderated bitcoin-bips@lists•sourceforge list.
>
>
> Let's stay away from SF.net or any mailman-controlled lists if at all
> possible. They break DKIM signatures which means they're no longer
> compatible with Yahoo, all mail from Yahoo users gets spamfoldered
> immediately. Google Groups gets this right. Perhaps other list operators do
> too. Groups also has moderation features.
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



 permalink raw reply	[|nested]
2014-10-15 15:46   ` Mike Hearn

  2014-10-15 16:47       ` 
                         ` 
  
From: Adam Back @ 2014-10-15 15:54 UTC (permalink / raw)
  To: Mike Hearn;  Bitcoin Dev

please not google groups *, I'd vote for sourceforge or other simple
open list software over google groups.

Adam

* Google lists are somehow a little proprietary or gmail lockin
focused eg it makes things extra hard to subscribe with a non-google
address if google has any hint that your address is associated with a
gmail account.  Quite frustrating.

On 15 October 2014 16:46, Mike Hearn <mike@plan99•net> wrote:
>> Great idea. Jeff Garzik was looking for a better mailing list solution
>> than SourceForge, but assuming
>> there isn't a clearly better solution I think "we" should create a
>> strictly moderated bitcoin-bips@lists•sourceforge list.
>
>
> Let's stay away from SF.net or any mailman-controlled lists if at all
> possible. They break DKIM signatures which means they're no longer
> compatible with Yahoo, all mail from Yahoo users gets spamfoldered
> immediately. Google Groups gets this right. Perhaps other list operators do
> too. Groups also has moderation features.
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>



 permalink raw reply	[|nested]
2014-10-15 15:54     ` Adam Back
  2014-10-15 16:47       ` Peter Todd

  2014-10-16  7:38         ` Thomas Zander
  2014-10-16 14:19         ` Oliver Egginger
  2014-10-15 19:00       ` Btc Drak
  
From: Mike Hearn @ 2014-10-15 18:13 UTC (permalink / raw)
  To: Adam Back;  Bitcoin Dev

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

I don't care much what exact list software/service is used, but lists.sf.net
hasn't changed in years and is basically dying. Trashing all @yahoo
accounts because ancient mailman does a MITM attack on people's email is no
good, it's not any better than a web proxy that breaks every SSL
connection. For a project that is based on digital signatures, it's really
bad that the mailing list is incompatible with Yahoo's "mail signatures
must be valid" policy.

Plus its moderation features suck, its mail archiving features suck, etc.
It essentially has no redeeming features at all.

mail-archive.com can be easily used with any mailing list, so not sure why
that's brought up. You just add it as a member, as documented here:
http://www.mail-archive.com/faq.html#newlist

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

 permalink raw reply	[|nested]
2014-10-15  9:36   ` Wladimir

  2014-10-16  7:50     ` Thomas Zander
  
From: Cory Fields @ 2014-10-15 18:58 UTC (permalink / raw)
  To: Wladimir;  Bitcoin Dev, Amir Taaki

Sounds like this is what you're after, it's a fairly new feature:
https://github.com/blog/1375%0A-task-lists-in-gfm-issues-pulls-comments

I've been meaning to use it in a PR to try it out.

Cory

On Wed, Oct 15, 2014 at 5:36 AM, Wladimir <laanwj@gmail•com> wrote:
>> This all makes a lot of sense to me, and would help a lot with the
>> workflow.  Unfortunately github pulls and issues really have nothing
>> to faciltate a multistage workflow... e.g. where something can go
>> through several steps.
>
> Indeed, pull requests don't have a "status".
> It would be possible to (ab)use labels for this.
>
> The drawback of labels is that only the repository team can set these,
> there is no way to delegate. But I suppose it'd be possible to build
> something on top of the github API that handles this.
>
>> We're also having problems with people failing to comment on things,
>> not even "I looked at this and have no opinion", which is really
>> obstructing things.
>
> Well - the only way to avoid that is to set a reasonable deadline,
> after which there is a default decision. You'd hope this would
> motivate people to get involved in time.
>
> Wladimir
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
> http://p.sf.net/sfu/Zoho
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 permalink raw reply	[|nested]
2014-10-15 15:54     ` Adam Back
  2014-10-15 16:47       ` Peter Todd
  2014-10-15 18:13       ` Mike Hearn

  2014-10-15 19:40         ` Peter Todd
  
From: Btc Drak @ 2014-10-15 19:00 UTC (permalink / raw)
  To: Adam Back;  Bitcoin Dev

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

On Wed, Oct 15, 2014 at 4:54 PM, Adam Back <adam@cypherspace•org> wrote:

> please not google groups *, I'd vote for sourceforge or other simple
> open list software over google groups.
>

Please not sourceforge.


> * Google lists are somehow a little proprietary or gmail lockin
> focused eg it makes things extra hard to subscribe with a non-google
> address if google has any hint that your address is associated with a
> gmail account.  Quite frustrating.


Mailman is good enough...

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

 permalink raw reply	[|nested]
2014-10-15 19:00       ` Btc Drak

  2014-10-16  4:41           ` Luke Dashjr
  
From: Peter Todd @ 2014-10-15 19:40 UTC (permalink / raw)
  To: Btc Drak;  Bitcoin Dev

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

On Wed, Oct 15, 2014 at 08:00:10PM +0100, Btc Drak wrote:
> > * Google lists are somehow a little proprietary or gmail lockin
> > focused eg it makes things extra hard to subscribe with a non-google
> > address if google has any hint that your address is associated with a
> > gmail account.  Quite frustrating.
> 
> 
> Mailman is good enough...

I used these guys for awhile to host a small mailman list with
absolutely no issues. Just $5/month for 1000 subscribers.

https://www.mailmanlist.net/

-- 
'peter'[:-1]@petertodd.org
000000000000000019e75ca8667f175b61a41ad950d15b61d83d3faf1a128f94

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

 permalink raw reply	[|nested]
2014-10-15 19:40         ` Peter Todd

  
From: Luke Dashjr @ 2014-10-16  4:41 UTC ( / )
  To: bitcoin-development

On Wednesday, October 15, 2014 7:40:04 PM Peter Todd wrote:
> On Wed, Oct 15, 2014 at 08:00:10PM +0100, Btc Drak wrote:
> > > * Google lists are somehow a little proprietary or gmail lockin
> > > focused eg it makes things extra hard to subscribe with a non-google
> > > address if google has any hint that your address is associated with a
> > > gmail account.  Quite frustrating.
> > 
> > Mailman is good enough...
> 
> I used these guys for awhile to host a small mailman list with
> absolutely no issues. Just $5/month for 1000 subscribers.
> 
> https://www.mailmanlist.net/

I've been using http://lists.nongnu.org/ for BFGMiner announce/dev mailing 
lists for a while. I don't know what software it runs, but it works.

Catch is that we'd need to go through Savannah's free software auditing.
That might be a good idea anyway?

Luke
2014-10-15 18:13       ` Mike Hearn

  2014-10-16 14:19         ` Oliver Egginger
  
From: Thomas Zander @ 2014-10-16  7:38 UTC (permalink / raw)
  To: Bitcoin Dev

On Wednesday 15. October 2014 20.13.11 Mike Hearn wrote:
> Plus its moderation features suck, its mail archiving features suck, etc.
> It essentially has no redeeming features at all.

Other than it being open source, an open platform with no lock-in 'features' 
and it works with everyone that uses the standards properly.
Naturally, if an old version fails to function with Yahoo, I'm all for finding 
a different provider. Thats what open platforms, like Mailman, are about.

-- 
Thomas Zander



 permalink raw reply	[|nested]
2014-10-15  9:36   ` Wladimir
  2014-10-15 18:58     ` Cory Fields

  
From: Thomas Zander @ 2014-10-16  7:50 UTC (permalink / raw)
  To: bitcoin-development

On Wednesday 15. October 2014 11.36.58 Wladimir wrote:
> > We're also having problems with people failing to comment on things,
> > not even "I looked at this and have no opinion", which is really
> > obstructing things.
> 
> Well - the only way to avoid that is to set a reasonable deadline,
> after which there is a default decision. You'd hope this would
> motivate people to get involved in time.

I have been part of both the OSI (NEN) and the OASIS standards committees for 
a while, working on standards as a technical adviser.

There I learned a lot about how to manage this process, maybe some ideas from 
such committees can be useful.

The idea that one person owns a BIP makes total sense, (s)he is the only one 
that should be putting forward the BIP when its mature enough for making it 
final. Note that this can be already after its been implemented once or twice.

So you have a phase where you have random people propose changes, which should 
all go in the public mailinglist, and they can be accepted by the owner 
without discussion.
If anyone that sees that change has an objection to the change, (s)he speaks 
up and you follow group consensus. This means (and this is actually in an ISO 
standard ;) that consensus is reached when nobody is left objecting to the 
change.

At some point the BIP is mature enough to vote on, at the discretion of the 
owner, and the owner puts it forward and requests a vote. If the above process 
was handled cleanly there is a very small chance of it being down-voted so an 
actual vote may not be needed (its hard to decide who gets a vote..).
You obviously need a deadline for this and afterwards you mark the proposal 
final. Or you close it as "needs more work".
-- 
Thomas Zander



 permalink raw reply	[|nested]
2014-10-15 18:13       ` Mike Hearn
  2014-10-16  7:38         ` Thomas Zander

  
From: Oliver Egginger @ 2014-10-16 14:19 UTC (permalink / raw)
  To: bitcoin-development

15.10.2014 at 20:13 Mike Hearn wrote:
> For a project that is based on digital signatures, it's really
> bad that the mailing list is incompatible with Yahoo's "mail signatures
> must be valid" policy.

# Mailman: Do not break existing DKIM signatures
DEFAULT_SUBJECT_PREFIX  = ""
DEFAULT_MSG_HEADER = ""
DEFAULT_MSG_FOOTER = ""

Maybe you should remove these settings. They make little sense and cause
apparently problems for some recipients.

Also the mail body must not be altered through advertising or something
else.

- oliver



 permalink raw reply	[|nested]
2014-10-15  8:29 [Bitcoin-development] BIP process Wladimir
  2014-10-15  9:22 ` Gregory Maxwell
  2014-10-15 15:37 ` Gavin Andresen

  2014-10-19  9:42   ` Btc Drak
                     ` (3 more replies)
  
From: xor @ 2014-10-19  7:17 UTC (permalink / raw)
  To: bitcoin-development

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

On Wednesday, October 15, 2014 10:29:43 AM Wladimir wrote:
> B) I also think it makes sense to move the BIP discussion (both about
> the BIP process and individual BIPs) to a separate mailing list.
> 
> bitcoin-development currently has a dual function: discussion of
> Bitcoin Core implementation concerns, as well as global changes to
> Bitcoin (in the form of BIPs).
> 
> This makes the list too busy for some people, but it is critical that
> everyone writing a Bitcoin node or client is up-to-date with proposals
> and can comment on them.

I joined the list when Bitcoin was already in the 10-billions of market 
capitalization, and it actually really surprised me how low the traffic is here 
given the importance of Bitcoin.

So as a random stranger to the project, I would vote against that if I was 
allowed to. There really should be *more* discussion here, and splitting the 
list up won't help with that.

Greetings

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

 permalink raw reply	[|nested]
2014-10-15  8:29 [Bitcoin-development] BIP process Wladimir
  2014-10-15  9:22 ` Gregory Maxwell
  2014-10-15 15:37 ` Gavin Andresen

  2014-10-19  9:42   ` 
                     ` 
  
From: xor @ 2014-10-19  7:17 UTC (permalink / raw)
  To: bitcoin-development

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

On Wednesday, October 15, 2014 10:29:43 AM Wladimir wrote:
> B) I also think it makes sense to move the BIP discussion (both about
> the BIP process and individual BIPs) to a separate mailing list.
> 
> bitcoin-development currently has a dual function: discussion of
> Bitcoin Core implementation concerns, as well as global changes to
> Bitcoin (in the form of BIPs).
> 
> This makes the list too busy for some people, but it is critical that
> everyone writing a Bitcoin node or client is up-to-date with proposals
> and can comment on them.

I joined the list when Bitcoin was already in the 10-billions of market 
capitalization, and it actually really surprised me how low the traffic is here 
given the importance of Bitcoin.

So as a random stranger to the project, I would vote against that if I was 
allowed to. There really should be *more* discussion here, and splitting the 
list up won't help with that.

Greetings

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

 permalink raw reply	[|nested]
* 
  2014-10-19  7:17 ` xor

  2014-10-19  9:49   ` 
                     ` 
  3 siblings, 0 replies; 24+ messages in thread
From: Btc Drak @ 2014-10-19  9:42 UTC (permalink / raw)
  To: xor;  Bitcoin Dev

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

On Sun, Oct 19, 2014 at 8:17 AM, xor <xor@freenetproject•org> wrote:

> I joined the list when Bitcoin was already in the 10-billions of market
> capitalization, and it actually really surprised me how low the traffic is
> here
> given the importance of Bitcoin.
>
> So as a random stranger to the project, I would vote against that if I was
> allowed to. There really should be *more* discussion here, and splitting
> the
> list up won't help with that.


I agree. This is also where the best peer review is to be found. Splitting
the list will dilute this.

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

^ permalink raw reply	[|nested] 24+ messages in thread
2014-10-19  7:17 ` xor
  2014-10-19  9:42   ` Btc Drak
  2014-10-19  9:49   ` Wladimir

  2014-10-20  0:33   ` odinn
  
From: Thomas Zander @ 2014-10-19 18:58 UTC (permalink / raw)
  To: bitcoin-development

On Sunday 19. October 2014 09.17.51 xor wrote:
> I joined the list when Bitcoin was already in the 10-billions of market 
> capitalization, and it actually really surprised me how low the traffic is
> here  given the importance of Bitcoin.

I gather that actual code changes to bitcoin-core and naturally all the other 
clients are already done in another place. Which is likely the reason for your 
impression.
 
> So as a random stranger to the project, I would vote against that if I was 
> allowed to. There really should be *more* discussion here, and splitting
> the  list up won't help with that.

I agree with your stance that more discussion in public is always good.

Lets allow people that work on bitcoin java, or completely other bitcoin based 
stuff to have a simple way to filter out the topics they are interested in.
Mailinglist handling is pretty trivial in practically all email software, 
people can equally trivially subscribe to multiple lists as their interests 
go.

As a long time open source developer, my experience is that more lists has 
never really caused fragmentation in the way that you fear.



 permalink raw reply	[|nested]
2014-10-19  7:17 ` xor
                     ` (2 preceding siblings ...)
  2014-10-19 18:58   ` Thomas Zander

  
From: odinn @ 2014-10-20  0:33 UTC (permalink / raw)
  To: bitcoin-development

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

Earlier in the discussion I suggested Discourse so that the BIP page
would be able to look smoother and draw more input.
Unsystem forum is run on Discourse and has twitter, github, and e-mail
integration.
For those who haven't explored it, here is what that looks / feels like:
https://forum.unsystem.net/

I'm curious as to why this sort of solution should or should not be
considered from someone else's perspective. In the end, whatever
works best for all concerned, I'm fine with it, but I'd like to hear
more about people's thoughts on Discourse. (I kind of like the feel
of it.)

xor wrote:
> On Wednesday, October 15, 2014 10:29:43 AM Wladimir wrote:
>> B) I also think it makes sense to move the BIP discussion (both 
>> about the BIP process and individual BIPs) to a separate mailing
>>  list.
>> 
>> bitcoin-development currently has a dual function: discussion of 
>> Bitcoin Core implementation concerns, as well as global changes 
>> to Bitcoin (in the form of BIPs).
>> 
>> This makes the list too busy for some people, but it is critical
>>  that everyone writing a Bitcoin node or client is up-to-date 
>> with proposals and can comment on them.
> 
> I joined the list when Bitcoin was already in the 10-billions of 
> market capitalization, and it actually really surprised me how low
>  the traffic is here given the importance of Bitcoin.
> 
> So as a random stranger to the project, I would vote against that 
> if I was allowed to. There really should be *more* discussion here,
> and splitting the list up won't help with that.
> 
> Greetings
> 
> 
> 
> ------------------------------------------------------------------------------
>
>
>
> 
Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month. Get alerted through email, SMS, 
> voice calls or mobile push notifications. Take corrective actions 
> from your mobile device. http://p.sf.net/sfu/Zoho
> 
> 
> 
> _______________________________________________ Bitcoin-development
> mailing list Bitcoin-development@lists•sourceforge.net 
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> 

- -- 
http://abis.io ~
"a protocol concept to enable decentralization
and expansion of a giving economy, and a new social good"
https://keybase.io/odinn

-----BEGIN PGP SIGNATURE-----

iQEcBAEBCgAGBQJURFhXAAoJEGxwq/inSG8Cpc0H+wZauz7iOj4XZJSI3VBv+5WL
YAe8kDSOpa5ZprFntsFfKVU+cmSjXckPjCRI9+LsrfTR2L+VjAimjQTct1m6oRAo
+5ZQ8Tn2CLEVRJRUzd8zbW8QPMuQCdzvwjs1oq8anaAPdwseEC/QhTZY6Av1MB8y
nH+05mMu4YeF3RRIyjXgvxDiBBK3knoaBkbsORkVbIb7MojUBy7FnsS1JFmSs8wv
XwWnkmFjVlhC8wSQYohcTWdJablxjpKRFq1ZNgDtIoXEi0dsC+G9Gc+8xub4hA/Y
nDk85ihX17TBbB47SOJEAdpGrJjkb8OvdX2ubLnQPYth82wX/MWJTTdv2a4JGik=
=uYGH
-----END PGP SIGNATURE-----



 permalink raw reply	[|nested]