-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 wh
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 natu
On Sun, Oct 19, 2014 at 9:17 AM, xor wrote:
> 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.
The problem is not one of traffic, but of confusion of concerns,
On Sun, Oct 19, 2014 at 8:17 AM, 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.
>
> So as a random stranger to the project, I would vote aga
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 c
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
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
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,
> afte
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 hi
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
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 wrote:
>> This all makes a lot of sense to me, and would he
On Wed, Oct 15, 2014 at 4:54 PM, Adam Back 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
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. F
On Wed, Oct 15, 2014 at 04:54:57PM +0100, Adam Back wrote:
> 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 subscr
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
>
> 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 i
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 solut
> 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
On Wed, Oct 15, 2014 at 8:29 AM, Wladimir wrote:
> 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
>
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 Bitco
On Thu, Oct 20, 2011 at 7:02 AM, Alex Waters 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
>
>
> • 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"
> • 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
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 (n
24 matches
Mail list logo
