y different
>
> than
>
> the one we had on the same topic 11 weeks ago:
> https://lists.apache.org/thread.html/
> raf3592f2297abfb120563d216eeea26bfb3a6e048b246492815954ff%40%3Cdev.
> cassandra.apache.org%3E
> .
>
> Jordan
> if we do these contributions in secret
Are you aware of any work happening (or expected to happen) in this way? This
seems a very different problem than the one the thread was opened with.
> it will be even harder for folk to put in late reviews
It is always harder to revert and revisit comm
m concerned a new branch will not change my main goal which is
to have 4.0 out of the door.
On Fri, Sep 11, 2020 at 11:03 AM Benedict Elliott Smith
wrote:
> This is a social enterprise, and we are all able to enter into a social
> contract/convention. This doesn't
r the benefit of the community. However, the community might together agree
to a partial-relaxation if it can be done safely.
On 11/09/2020, 04:09, "Jeff Jirsa" wrote:
> On Sep 10, 2020, at 2:42 PM, Benedict Elliott Smith
wrote:
>
>
>>
>> As
people using the branch seems to
mitigate that concern.
Also, when 4.0 GA'ed wouldn't we just trunk become a 4.0 branch and then
cassandra-5.0 become trunk?
On Thu, Sep 10, 2020 at 4:32 PM, Benedict Elliott Smith wrote:
> We know we are turning away more and more
> We know we are turning away more and more contributions
Do we? I haven't been aware of much of this occurring at all.
On 10/09/2020, 20:58, "Mick Semb Wever" wrote:
We know we are turning away more and more contributions and new potential
dev community with our 4.0 feature freeze, a
+1
On 01/09/2020, 20:09, "Caleb Rackliffe" wrote:
+1
On Tue, Sep 1, 2020, 2:00 PM Jasonstack Zhao Yang
wrote:
> +1
>
> On Wed, 2 Sep 2020 at 02:45, Dinesh Joshi wrote:
>
> > +1
> >
> > > On Sep 1, 2020, at 11:27 AM, David Capwell wrote:
> > >
> SAI will follow the same QA/Testing guideline as in CASSANDRA-15536.
CASSANDRA-15536 might set some good examples for retrospectively shoring up our
quality assurance, but offers no prescriptions for how we approach the testing
of new work. I think the project needs to conclude the discussion
ail-archive.com/user@cassandra.apache.org/msg60234.html
Jordan
On Mon, Aug 10, 2020 at 4:16 AM Benedict Elliott Smith
wrote:
> Have we considered first asking the user list if there's anyone willing to
> donate resources to maintain compatibility?
>
>
Have we considered first asking the user list if there's anyone willing to
donate resources to maintain compatibility?
I know I have in the (distant) past handled Jira filed by (production) Windows
users. I don’t know how prevalent they are, but perhaps we should offer them a
chance to step up
+1
On 06/08/2020, 10:07, "Michael Semb Wever" wrote:
> I think the pragmatic thing to do is fix it now, and I'd strongly
> prefer to do that but wanted to check if there are any objections or
> things I hadn't considered?
+1
Thanks for giving this visibility and demonstr
when
Impacts = Docs.
Thanks for the info, Benedict!
Lorina Poland
On Fri, Jul 31, 2020 at 1:10 PM Benedict Elliott Smith
wrote:
> > It is mandatory to move a ticket to "In Progress"
>
> I think you are mistaken; I have triple-checked, a
nt, I can look at the code and
figure out what it does. A topic like audit logging is likely to use many
classes and touch on many items that I'm not familiar with nor be the most
readable code.
Lorina Poland
On Fri, Jul 31, 2020 at 12:35 PM Benedict Elliott Smith
w
Impacts -> Docs
It's not mandatory, but we could perhaps consider making it so somewhere in the
workflow. Do you have a good suggestion for where?
There's also "Test and Documentation Plan" which is already mandatory.
On 31/07/2020, 20:28, "Lorina Poland" wrote:
This morning, Caleb Rac
not
taking this discussion further. Just want to call it out here so you or
others aren't left waiting for a reply.
We can agree to disagree.
On Mon, Jul 20, 2020 at 11:59 AM Benedict Elliott Smith
wrote:
> Firstly, that is a very strong claim that in this particul
ause of the action you took;
Actually, in this case and many others it's because of people's unfounded
assumptions about motives, incentives, and actions taken and has little to
do with reality. Which is the definition of not assuming positive intent.
On Mon, Jul 20,
Thanks Sally, really appreciate your insight.
To respond to the community discourse around this:
> Keep your announcement plans ... private: limit discussions to the PMC
This is all that I was asking and expecting: if somebody is making commitments
on behalf of the community (such as that a rel
t of diminishing returns and we're
fine just being a bit more laissez-faire about things and applying our
collective judgement through our votes on each instance. My own bias
though, definitely receptive to other points of view on that.
On Fri, Jul 17, 2020 at 11:21 AM B
etc) with marketing material and the ASF blog post that's lined up for the
project.
On Fri, Jul 17, 2020 at 5:14 AM Benedict Elliott Smith
wrote:
> -1
>
> Sorry, I dropped the ball on
> https://issues.apache.org/jira/browse/CASSANDRA-15375
&
-1
Sorry, I dropped the ball on
https://issues.apache.org/jira/browse/CASSANDRA-15375
It's ready to commit, if somebody can give it a quick +1, and would be
prohibited after first beta.
On 16/07/2020, 21:16, "Sumanth Pasupuleti"
wrote:
+1 nb
Ran following CircleCI tests
j8_uni
gagement with the project outside a
small subset of the population with resources to dedicate to this type of
testing which I think we don't want.
On Wed, Jul 15, 2020 at 11:53 AM Benedict Elliott Smith
wrote:
> Perhaps you could clarify what you personally hope w
that's table stakes. But agreeing on how we
> get
> > there, my personal take is we'd all be well served to spend our energy
> > Doing the Work and expressing these complementary positions rather than
> > trying to bend everyone to one consistent poin
It does raise the bar to critiquing the document though, but perhaps that's
also a feature.
Perhaps we can first discuss the purpose of the document? It seems to be a mix
of mission statement for the project, as well as your own near term roadmap?
Should we interpret it only as an advertisemen
+1
On 03/07/2020, 10:57, "Oleksandr Petrov" wrote:
Proposing the test build of in-jvm dtest API 0.0.3 for release.
Repository:
https://gitbox.apache.org/repos/asf?p=cassandra-in-jvm-dtest-api.git;a=shortlog;h=refs/tags/0.0.3
Candidate SHA:
https://github.com/apache/cassan
Yep, agreed this is definitely the best route forwards.
On 02/07/2020, 01:10, "Joshua McKenzie" wrote:
Plays pretty cleanly into the "have a test plan" we modded in last month. +1
On Wed, Jul 1, 2020 at 6:43 PM Nate McCall wrote:
> >
> >
> >
> > If so, I propose we se
I humbly suggest these are the wrong questions to ask. Instead, two sides of
just one question matter: how did we miss these problems, and what would we
have needed to do procedurally to have not missed it. Whatever it is, we need
to do it now to have confidence other things were not missed, a
ere are no plans to stop working on it going forward.
On Tue, Jun 30, 2020 at 5:45 PM Benedict Elliott Smith
wrote:
> I don't think we can realistically expect majors, with the deprecation
> cycle they entail, to come every six months. If nothing else, we would
I don't think we can realistically expect majors, with the deprecation cycle
they entail, to come every six months. If nothing else, we would have too many
versions to maintain at once. I personally think all the project needs on that
front is clearer roadmapping at the start of a release cycl
I think, just as importantly, we also need to grapple with what went wrong when
features landed this way, since these were not isolated occurrences -
suggesting structural issues were at play.
I'm not sure if a retrospective is viable with this organisational structure,
but we can perhaps engag
and it does
not push me in a direction or another.
Of course, our opinions are somehow tainted by our organizations but that
does not mean that individuals can be reduced to their organization.>
On Mon, Jun 29, 2020 at 2:33 PM Benedict Elliott Smith
wrote:
> I bel
need both new features/improvements and stability.
It is natural that some people push a bit more towards new
features\improvements and others towards stability.
I would be worried if everybody wanted to go in the same direction.
On Mon, Jun 29, 2020 at 12:22 PM Benedict Elliott Smi
On Sun, Jun 28, 2020 at 12:07 AM Benedict Elliott Smith
wrote:
> > Just a heads up - this comes across as passive aggressive sniping. I'm
> sure you didn't mean it as such
>
> I think indirect criticism is a normal part of discourse, particula
> Just a heads up - this comes across as passive aggressive sniping. I'm sure
> you didn't mean it as such
I think indirect criticism is a normal part of discourse, particularly in
public fora where it can be more polite and less disruptive than direct
criticism. Ironically, this snippet of yo
ests, or you pay money to be able to
run the tests... If the intent is to make it easier for new people to
contribute to the project, shouldn't the focus be on fixing their pain
points such as testing?
On Fri, Jun 26, 2020 at 3:38 PM Jordan West wrote:
> On Fri, Jun 26
> Nothing is stopping us for discussing CEPs now, and nothing prevents folks
> from making their own feature branches.
I disagree. CEPs are just as - if not more - of a distraction than branching.
Work doesn't happen in a vacuum. Those who are today focusing what resources
they can on shippin
Ok, I'm sorry for reaching the opposite conclusion before reading this email -
the implication here instead appears to be that, you believe, people are
advocating to integrate work that should be deferred - is that correct?
Perhaps we should have a direct conversation about the tickets you cons
--> Branching anytime before we 4.0.0 adds extra burden to the folks trying to
get 4.0.0
This. This is all that matters IMO. Some have been saying 4.0.0 is very
delayed, and that this harms the project - and they're right. So I'm surprised
to see those same voices advocating we prioritise th
The purpose of this document is to define only how the project makes decisions,
and it lists "tenets" of conduct only as a preamble for interpreting the rules
on decision-making. The authors' intent was to lean on this to minimise the
rigidity and prescriptiveness in the formulation of the rule
Also, +1
On 22/06/2020, 11:23, "Benedict Elliott Smith" wrote:
If you read the clauses literally there's no conflict - not all committers
that +1 the change need to review the work. It just means that two committers
have indicated they are comfortable with the patch bei
If you read the clauses literally there's no conflict - not all committers that
+1 the change need to review the work. It just means that two committers have
indicated they are comfortable with the patch being merged. One of the +1s
could be based on another pre-existing review and trust in bo
but not so much that I think we'll end up backed into
a corner. I didn't do a good job of explaining that though.
Might be useful to take a roll call now just to get a feel for what we're
voting for.
On Thu, Jun 18, 2020 at 11:21 AM Benedict Elliott Smith
wr
thing that would be a non-issue assuming positive intent and
> > alignment
> > > between response to roll call and participation.
> > >
> > >
> > > On Wed, Jun 17, 2020 at 8:08 PM Yifan Cai wrote:
> > >
> > >> +1 nb
> > &g
at 12:30 PM Jon Haddad
wrote:
>>> > >
>>> > > > I'm not concerned today, no, just musing and pointing out that
>>> there
>>> > are
>>> > > easy ways to improve progress if we find there's an impedi
> >
> > Yeah, I didn't think you were serious about it being a problem, just
> wanted
> > to check.
> >
> > I'm changing my vote to a -1, in favor of a simple majority as the low
> > watermark in vote participation (not appr
ou're concerned about, or just musing over?
On Wed, Jun 17, 2020 at 9:21 AM Benedict Elliott Smith
wrote:
> Sorry, I've been busy so not paid as close attention as I would like after
> initial contributions to the formulation. On the document I raised this
as
&g
Sorry, I've been busy so not paid as close attention as I would like after
initial contributions to the formulation. On the document I raised this as an
issue, and proposed lowering the "low watermark" to a simple majority of the
electorate - since if you have both a simple majority of the "act
ts surfaced by a diverse
collection of users and I'd like to see us move in that direction again for
the long-term health of the project. Hence my attempts to move us towards
beta and take on an awareness campaign and call to action for the community
to engage in testing.)
O
ave a alpha release)?
This has been confusing me since beta has a lot of work pending… sorry for
not bring this up in a dedicated dev@ thread
>
> On Tue, Jun 16, 2020 at 4:58 PM Benedict Elliott Smith
> wrote:
>
>> So, if it helps matters: I am explicit
+1
On 16/06/2020, 22:23, "Nate McCall" wrote:
+1 (binding)
On Wed, Jun 17, 2020 at 4:19 AM Joshua McKenzie
wrote:
> Added unratified draft to the wiki here:
>
>
https://cwiki.apache.org/confluence/display/CASSANDRA/Apache+Cassandra+Project+Governance
>
> I pr
So, if it helps matters: I am explicitly -1 the prior version of this work due
to the technical concerns expressed here and on the ticket. So we either need
to revert that patch or incorporate 15299.
On 16/06/2020, 21:48, "Mick Semb Wever" wrote:
>
> 2) Alternatively, it's been 3 yea
rote:
Oh, interesting. I checked the doc and didn't see a time frame on the roll
call but maybe I just missed it.
I'll open it up for comments either way.
On Thu, Jun 4, 2020 at 5:51 PM Benedict Elliott Smith
wrote:
> I think the 24 hours point that was raised was
I think the 24 hours point that was raised was pointed to being too short was
just for the roll-call; I personally that think for closing down a discussion,
24 hours is acceptable in order to assist progress, since it should only be
called when it's clear the discussion has halted or consensus h
I think the doc is a great place to reach agreement on things that are easily
agreed - the final form will be moved to the wiki anyway, and voted on here.
Anything that isn't readily agreed should be moved here for further discussion,
in my opinion, to widen participation.
On 04/06/2020, 22:4
> It seems all rules on voting are predicated on the question being binary
ASF votes are meant to be - as far as possible - a formality confirming
consensus, or something to resolve irreconcilable disagreements. The
discussion section describes how to build consensus when there are multiple
o
ow]" because it
invalidates "4.0 Verification Work" must also be prohibited until "5.0 Dev"
because the next equivalent work that can now validate it occurs only at "5.0
Verification Work"
On 27/05/2020, 19:05, "Benedict Elliott Smith" wrote:
I
d important places but the important thing is
> to see how exactly it touches, I think
> - Considering it for alpha before the major testing in beta sounds
> reasonable to me but I guess it also depends on people availability to
> review it in detail and the exact
I think our "pre-beta" criteria should also be our "not in a major" criteria.
If work is prohibited because it invalidates our pre-release verification, then
it should not land until we next perform pre-release verification, which only
currently happens once per major.
This could mean either l
I vote to nuke it post-4.0, when we have time to put together a working group
to discuss its replacement.
On 30/04/2020, 19:21, "Mick Semb Wever" wrote:
The C* codebase contains the cassandra-stress tool that is seeing less
maintenance and is getting replaced in popularity by other too
pache fundation, and maybe I'm just stating the obvious here.
[1] fwiw, I say this as someone that at some points in time was
simultaneously
somewhat actively involved in both Cassandra and the DataStax Java driver.
--
Sylvain
On Fri, Apr 24, 2020 at 12:54 AM Ben
above.
On 22/04/2020, 21:25, "Nate McCall" wrote:
On Thu, Apr 23, 2020 at 5:37 AM Benedict Elliott Smith
wrote:
> I welcome the donation, and hope we are able to accept all of the
> drivers. This is really great news IMO.
>
> I do however won
I welcome the donation, and hope we are able to accept all of the drivers.
This is really great news IMO.
I do however wonder if the project may be accumulating too many sub-projects?
I wonder if it's time to think about splitting, and perhaps incubating a
project for the drivers?
On 22/0
+1. This might also serve to produce specific points of discussion around the
topic as the CEP progresses.
Maybe put it high up the list, e.g. after Description of Approach?
On 22/04/2020, 17:40, "Joshua McKenzie" wrote:
Link to CEP guide:
https://cwiki.apache.org/confluence/pages/
such and do not assume
negative intent.
On Thu, Apr 16, 2020 at 9:18 AM Benedict Elliott Smith
wrote:
>
> This is a silly pet peeve. In this context it was unambiguous what was
meant, and to snipe at people who do not have English as their first language
in such an ir
This is a silly pet peeve. In this context it was unambiguous what was meant,
and to snipe at people who do not have English as their first language in such
an irrelevant context is a waste of everyone's time and energy.
Please update your approach to the community.
On 16/04/2020, 10:35, "Gr
> become much easier to agree on which tickets we put in 4.0.
>
>
>
>
>
>
>
>
> On Sun, Apr 5, 2020 at 1:25 AM Benedict Elliott Smith >
> wrote:
>
> > There it is. I knew it would show up eventually.
+1
On 08/04/2020, 16:53, "Mick Semb Wever" wrote:
Can we agree on keeping such test changes out of CHANGES.txt ?
We already don't put entries into CHANGES.txt if it is not a change
from any previous release.
There was some discussion before¹ about this, and the problem
There it is. I knew it would show up eventually.
On 04/04/2020, 06:26, "bened...@apache.org" wrote:
> scope creep.
I think it is unfair to label this scope creep; it would have to be newly
considered for 4.0 for it to fall under that umbrella.
I don't personally mind if
Sorry if this is a repeat message; I messed up my mail client settings (I don't
see it today, but it might just be stuck in an unmonitored moderator queue):
I think it is unfair to label this scope creep; it would have to be newly
considered for 4.0 for it to fall under that umbrella, surely?
I
I would personally prefer we simply bump tickets from the milestone
periodically. The point of a milestone is to collect tickets we expect to land
there, and since we want to release ASAP we should have at most a handful of
optional items there sponsored by some community members, so the burden
ose that work on a variety of machines over
time, this does represent a sub-optimal arrangement.
On Tue, Mar 24, 2020 at 4:38 PM Benedict Elliott Smith
wrote:
> You could push to the repository that triggers CI less frequently? I
> don't thi
You could push to the repository that triggers CI less frequently? I don't
think it cares about commits, but pushes.
I think some people like to see feedback promptly, without having to go in
manually until a dtest run is needed closer to patch completion. Unfortunately
this is a situation wh
Behaviours don't have to be switched only with a new protocol version; it's
possible to support optional feature/modifier flags, the support for which is
negotiated with a client on connection.
A protocol version change seems reasonable to limit to major releases, but a
protocol feature seems p
PRs on clean runs won’t
> achieve anything other than dealing with folks who straight up ignore the
> spirit of the policy and knowingly commit code with test breakage that can
> be attributed to their change. I’m not aware of such committers in this
> community, however
nt wouldn't be made in Jira, it probably shouldn't be
made.
On 24/01/2020, 08:56, "Benedict Elliott Smith" wrote:
The common factor is flaky tests, not people. You get a clean run, you
commit. Turns out, a test was flaky. This reduces trust in CI, so people
commi
The common factor is flaky tests, not people. You get a clean run, you commit.
Turns out, a test was flaky. This reduces trust in CI, so people commit
without looking as closely at results. Gating on clean tests doesn't help, as
you run until you're clean. Rinse and repeat. Breakages accum
This is brought up roughly once per year. If anything, you're a bit behind
schedule
https://lists.apache.org/thread.html/0750a01682eb36374e490385d6776669ac86ebc02efa27a87b2dbf9f%40%3Cdev.cassandra.apache.org%3E
https://lists.apache.org/thread.html/c21ccedc7fbda18558997dee8f86c074514b67387858ec12
t was
delivered.
On 15/01/2020, 13:34, "Benedict Elliott Smith" wrote:
I think there's always been a distinction in the way we treat alphas/betas
versus patch releases, because they have a staged delivery (landing for dev and
users in different releases). I don't kno
I think there's always been a distinction in the way we treat alphas/betas
versus patch releases, because they have a staged delivery (landing for dev and
users in different releases). I don't know we've ever been totally consistent
about it across major versions though.
I think we can view 4.
> I think as long as we all believe we're all good faith actors, truly believe
> we all want what's best for the project (even if we don't necessarily all
> agree on what that is all the time), and internalize that nobody wants to see
> a monoculture on the project, we'll be fine.
I realised re
Kohli" wrote:
>
>The Agenda is public and everyone will contribute to it. Anyone can
attend the meeting. Anyone can propose an alternate time. How is it private ?
>
>What else do you suggest ?
>
>> On Jan 11, 2020, at 9:31 AM, Benedict
nyone can propose an alternate time. How is it private ?
What else do you suggest ?
> On Jan 11, 2020, at 9:31 AM, Benedict Elliott Smith
wrote:
>
> I think everyone is missing my point, and the reason for it. I am super
focused on not repeating the situati
thread.
https://lists.apache.org/thread.html/aa54420a43671c00392978f2b0920bc6926ca9ba1e61a486ad39fb21%40%3Cdev.cassandra.apache.org%3E
On Sat, Jan 11, 2020 at 3:16 AM Benedict Elliott Smith
wrote:
> I recall this being discussed at ApacheCon, and I recall the ide
ting to the dev list.
Hugs and kisses friends,
- Jeff
> On Jan 10, 2020, at 6:05 PM, Benedict Elliott Smith
wrote:
>
> To be clear, as it seems like I'm being very negative here, I'm really
pleased to see DataStax suddenly increase their
s allowed
to use his time to try and get some people together to discuss contributing?
-Jeremiah Jordan
Person with no formal role in the Apache Cassandra project.
> On Jan 10, 2020, at 7:44 PM, Benedict Elliott Smith
wrote:
>
> This is also great. But i
ge.
Patrick
On Fri, Jan 10, 2020 at 3:21 PM Jeff Jirsa wrote:
> On Fri, Jan 10, 2020 at 3:19 PM Jeff Jirsa wrote:
>
> >
> >
> > On Fri, Jan 10, 2020 at 2:35 PM Benedict Elliott Smith <
> > bened...@apache.org> wro
Yes, I also miss those fortnightly (or monthly) summaries that Jeff used to
do. They were very useful "glue" in the community. I imagine they'd also make
writing the board report easier.
+1, those were great
-
To uns
> Isn’t this the point of project management; to avoid this issue?
Is the point of project management to avoid the problems caused by project
management? That feels like a Dilbert cartoon.
To be clear, I'm simply responding to the apparent suggestion that we assign
every 4.0 ticket to somebod
they are and add what value I can
and work with the project to help keep momentum high and remove blockers or
stalls from people's workflows.
Does the above make sense?
On Fri, Jan 10, 2020 at 8:30 AM Benedict Elliott Smith
wrote:
> I persona
I personally welcome your increased participation in any role, and more focus
on project delivery is certainly a great thing. But developer time from your
employer would probably be more impactful, as the main active contributors
right now have their own project management infrastructure, and a
+1
On 01/11/2019, 12:33, "Mick Semb Wever" wrote:
Please vote on accepting the Cassandra Enhancement Proposal (CEP) document
as a starting point and guide towards improving collaboration on, and success
of, new features and significant improvements. In combination with the recently
accep
+1
On 25/10/2019, 13:59, "Joshua McKenzie" wrote:
+1
On Thu, Oct 24, 2019 at 4:39 PM Nate McCall wrote:
> +1
>
>
> On Fri, Oct 25, 2019 at 6:25 AM Michael Shuler
> wrote:
>
> > I propose the following artifacts for release as 2.2.15.
> >
>
+1
On 25/10/2019, 13:58, "Joshua McKenzie" wrote:
+1
On Thu, Oct 24, 2019 at 4:39 PM Nate McCall wrote:
> +1
>
>
> On Fri, Oct 25, 2019 at 6:31 AM Michael Shuler
> wrote:
>
> > I propose the following artifacts for release as 3.0.19.
> >
>
+1
We need to do something about this, and I don't mind what. It would be better
if we cut fix releases immediately after a critical fix lands, much as we used
to. We've got fairly lazy about producing releases, perhaps because many of
the full-time contributors now work for organisations tha
+1
On 09/10/2019, 17:50, "Oleksandr Petrov" wrote:
Hi,
During NGCC/ACNA19 we've had quite a few conversations around the 4.0
release. Many (minor) features and changes suggested during that time are
possible to implement in 4.next without any problem. However, some changes
>> This has definitely been a confusing topic in the past, I completely
agree
>> Benedict. Glad you brought this up.
>>
>> I'm 100% on board with 5.0 after 4.0.
>>
>> On Tue, Oct 8, 2019 at 2:27 PM Benedict Elliott Smith
>>
As a brief side-step on the topic only of versioning (which no doubt will cause
enough consternation), I personally endorse streamlining it. We have not had a
consistently meaningful convention on this, at any point, and we made it even
worse in the 3.x line. There's no real difference between
Perhaps we should move the proposed document to the cwiki for purposes of
voting? That way it's in a place owned by the project, with a permanent
history. Otherwise it's not entirely clear what was voted on.
On 30/09/2019, 20:10, "Sumanth Pasupuleti"
wrote:
+1
On Mon, Sep 30,
with what you've stated here bes: "participation in decision-making is
costly, and that proposers should understand that they need to work to
lower the cost of decision-making on their proposal, and that we as a
project need to figure out how to help them do this.&quo
Lazy consensus still requires a formal vote, just one that is declared to be
governed by lazy consensus.
I think we need to spend some time formalising our governance, so that we can
employ it confidently. At the very least, we should try to codify where we are
comfortable employing lazy conse
e, Sep 17, 2019 at 3:44 AM Benedict Elliott Smith
wrote:
> Can we modify the document to make this really explicit then? Right now,
> the language suggests the process is mandated, rather than encouraged and
> beneficial.
>
> It would be nice to frame it
101 - 200 of 400 matches
Mail list logo