i agree 100%. effective communication is challenging, especially in an
environment like this. that being said, alicexbt is probably right that
we
- probably need a well written spec, RFC-style perhaps
- need more anon or nym maintainers where the online reputation isn't
trivially linked to
I don't see any reason to be antagonistic in your responses.
One piece of advice I'd offer to you and Michael is to consider whether
your responses are effective. To persuade other people it takes more than
making good points or being right, but you need to find a communication
style and
Hi Andrew,
> We can take a look at how previous maintainers were added to see how this has
> played out in the past.
Can we learn something from past?
Bitcoin's initial release was in 2009 with one developer and few others
experimenting with it. It is considered decentralized in 2023 however
Thanks for this Andrew.
> However I later spoke to a few others privately who were more familiar with
> Vasil's work and they had told me that they were not comfortable with Vasil
> being P2P maintainer.
Some individuals who will stay anonymous and who were more familiar with
Vasil's work
On 05/07/23 03:03 AM, Michael Folkson via bitcoin-dev wrote:
> The decision process for adding a new maintainer was according to the IRC
> meeting that the maintainers decided privately there was a need for a
> maintainer “who understood our interfaces and modularization efforts well”
> and
I see it was merged since my original post. I agree that is a very short
window of time. In particular, if a long-time Core contributor wasn't able
to attend the in-person meeting or last week's IRC meeting, they'd have had
to really been on the ball.
On Wed, May 10, 2023 at 10:22 AM Michael
> Blocking Vasil was discussed on a similar GitHub PR. Whether or not one
> agrees or disagrees, the same process is being used. Anyone can NACK and give
> a reason for Russ as well.
With respect Steve the process for Vasil was keeping Vasil's PR open for up to
5 months with zero NACKs and two
Blocking Vasil was discussed on a similar GitHub PR. Whether or not one
agrees or disagrees, the same process is being used. Anyone can NACK and
give a reason for Russ as well.
On Wed, May 10, 2023 at 8:55 AM Michael Folkson <
michaelfolk...@protonmail.com> wrote:
> Hi Steve
>
> > Isn't this as
Hi Steve
> Isn't this as simple as anyone (in particular Core project contributors) can
> express their view in this PR?https://github.com/bitcoin/bitcoin/pull/27604
Nope. The extent to which the rationale for blocking Vasil as a maintainer
applies or doesn't apply to ryanofsky (or future
Isn't this as simple as anyone (in particular Core project contributors)
can express their view in this PR?
https://github.com/bitcoin/bitcoin/pull/27604
On Mon, May 8, 2023 at 5:03 AM Bryan Bishop via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Sun, May 7, 2023 at 12:36 PM
On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
> > Essentially my concern is going forward current maintainers will
> > decide which proposed new maintainers to add and
Hi David
>> Essentially my concern is going forward current maintainers will decide
>> which proposed new maintainers to add and which to block.
> This is how a large percentage of organizations are run. The current members
> of a board or other governance group choose who will become a new
On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
Essentially my concern is going forward current maintainers will
decide which proposed new maintainers to add and which to block.
This is how a large percentage of organizations are run. The current
members of a board or other
There has been a proposed new maintainer on Bitcoin Core (ryanofsky). In the
Core dev IRC meeting [0] yesterday it received multiple ACKs.
The decision process for adding a new maintainer was according to the IRC
meeting that the maintainers decided privately there was a need for a
maintainer
Right, that's why I do not participate any longer, they specify things
for the participants (ie big companies), they disregard whatever
suggestion can be made, they are so slow that when they have specified
something someone else has specified something better, then they throw
away their spec and
i think the w3c is a very good example of a slow train wreck, and we should
do everything possible to avoid the decisions they made
On Thu, Apr 20, 2023 at 7:09 AM Aymeric Vitte via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Personnally I will never criticize the maintainers,
Personnally I will never criticize the maintainers, but my comment was
about the global process, I thought that for something important like
bitcoin there were many devs/maintainers, and as you point out, a PR
must be done by certified people
I don't get very well why every company involved in
Thanks for this Andrew.
> What commentary does there need to be?
There doesn't "need" to be explanations about anything. There doesn't "need" to
be any review comments whatsoever from anybody. But a world where reviewers
explain what they've done to satisfy themselves that a pull request is
Hi AJ
> Competition is the only answer to concerns about the bad effects from a
> monopoly.
Well one can first make suggestions and requests to the monopoly and see if the
monopoly is open to them. In the case of bitcoin-inquisition/default signet I
like the idea of a group who are interested
On Tue, Apr 18, 2023 at 12:40:44PM +, Michael Folkson via bitcoin-dev wrote:
> I do think the perception that it is “the one and only” staging
> ground for consensus changes is dangerous
If you think that about any open source project, the answer is simple:
create your own fork and do a
Hi Michael,
I will share something even though you didn't let me write things on several
occasions on github, twitter etc.
Try this:
- As Gloria said (respect people you don't like and shared something against),
create a competition for Brink. Fund bitcoin developers.
- Do more reviews
Responses in-line.
Note that the opinions expressed in this email are my own and are not
representative of what other maintainers think or believe.
On 04/18/2023 08:40 AM, Michael Folkson via bitcoin-dev wrote:
>
> Communication has been a challenge on Bitcoin Core for what I can
tell the
The different emails are overlong, it's difficult to follow
It is super surprising to see that Bitcoin has only 4 maintainers funded
by Brink and Blockstream, but I think the decisions are taken elsewhere
And I think the job of the maintainers is not only to be maintainers but
to do the PR
Hi alicexbt
> I don't think commentary is required for each pull request that gets merged
> with enough reviews, ACKs and no controversy.
The problem is defining what is "enough". "Enough" is determined by the quality
of the review, the expertise of the reviewer(s), the complexity of the pull
Hi Michael,
I was initially sad about the politics in Vasil's pull request, written about
it and also tried to document the process. Still think he deserves to be a
maintainer. Although I have some counter arguments:
> Maintainers merge a pull request and provide no commentary on why they’ve
Hi Erik
> yes, the code itself was far less contentious than the weird stab at forking
> the network
>
> there remains a real chance that bip 119 is the simplest and most flexible
> and reasonably safe covenant tech for many use cases
>
> although im partial to 118 as well because lightning is
yes, the code itself was far less contentious than the weird stab at
forking the network
there remains a real chance that bip 119 is the simplest and most flexible
and reasonably safe covenant tech for many use cases
although im partial to 118 as well because lightning is a killer app and it
Communication has been a challenge on Bitcoin Core for what I can tell the
entire history of the project. Maintainers merge a pull request and provide no
commentary on why they’ve merged it. Maintainers leave a pull request with many
ACKs and few (if any) NACKs for months and provide no
28 matches
Mail list logo
