Dear Cassandra contributor,
We are doing research on understanding how developers manage a special kind
of Technical Debt in *Java.*
We kindly ask 15-20 minutes of your time to fill out our survey. To help
you decide whether to fill it in, we clarify two points.
“Why should I answer this
I completely agree we should consider any roadmap a living document that we
expect to revise, but my hope is that we will formalise an agreed roadmap by
vote. My view is that we should aim to regularly revisit the roadmap, and
anticipate that it will be revised based on contributors' shifting
Having an open discussion about what we want to release as a community on
the next version makes total sense to me. I also agree that the roadmap
should not be written on stone and that we should be flexible if we believe
that we need to.
We should also take this discussion as an opportunity to
To say it another way, I would expect that once a roadmap is agreed we would
ensure there was a CEP for every item. I don't know whether every CEP would
necessarily be voted into a roadmap, nor whether every item voted on would have
a CEP before the vote is conducted, and don't have a strongly
I guess I meant that I don't foresee roadmap discussions having a hard
requirement of CEP for all goals we might discuss, though it would probably be
expected that many of the biggest proposals would already at least have a
minimal CEP to be filed, you're right.
Certainly if an advanced CEP
>
> I think of a roadmap as a pre-CEP activity for upcoming releases, items
> thereon beginning the CEP process, with target releases being assigned by
> the roadmap (subject to revision) and project members opting-in to the
> endeavour to deliver for that release.
I am a bit confused by that
>
> I think of a roadmap as a pre-CEP activity for upcoming releases, items
> thereon beginning the CEP process, …
>
What about having it the other way around? That the roadmap is a
visualisation of the CEPs, i.e. those past initial triage that have initial
commitment and momentum. A reflective
Yes, absolutely my goal isn't to prohibit work outside of the roadmap.
For really large, complex items of work that potentially require wide input
from community e.g. because of semantic or stability implications (i.e. the
kind we only deliver a handful per release), I think it would be
+1 to the idea of the project roadmap and the said benefits for planning.
In my opinion, it certainly does a world of good for visibility on what is
in the works/ what to look forward to for both the developers as well as
users. So long as "allowed work" is not restricted to items in the project
A while back somebody privately raised the idea of a project roadmap to me, and
I’d like to propose we formally consider it as a project now that 4.0 is
approaching completion.
I think there are two major benefits to agreeing a roadmap:
1) It helps us to coordinate finite project
A huge thanks to everybody that contributed to the new website. All your
efforts have paid off. That is truly an amazing work!
Le lun. 1 mars 2021 à 03:08, Ben Bromhead a écrit :
> Awesome stuff, looks great!
>
> On Mon, Mar 1, 2021 at 9:33 AM Nate McCall wrote:
>
> > Thanks Melissa! This
11 matches
Mail list logo
