-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
>
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
22 matches
Mail list logo
