> > 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 part. My understanding was that the CEPs will represent some of the big blocks of a release. By consequence, I would have believed that we would first discuss some CEPs and then create a roadmap based on the CEPs we agreed upon and the other improvement work we intend to do in parallel. Do you mind elaborating a bit more on what you will put in the roadmap if it will happen before the CEPs activity. Le lun. 1 mars 2021 à 11:31, Benedict Elliott Smith <bened...@apache.org> a écrit : > 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 > legitimate (and helpful) for the community to pause integration of work > until either the roadmap can be adjusted (to deprioritise other items > taking its focus) or until the roadmap catches up. The community has only > so much capacity for those kinds of contributions each release, and I think > it is beneficial to the project to manage that capacity, and also to ensure > such major contributions get due attention. But only the biggest > organisations are going to be even remotely constrained by this, and > they're able to re-shape the roadmap, so it's less a restriction and more a > mechanism to ensure collaboration and communication on the riskiest > contributions. > > This is of course all up for debate, but I think this would be both a > benefit of a roadmap, and also strengthen its other utilities by helping > keep the roadmap accurate and honest. > > > On 01/03/2021, 10:16, "Sumanth Pasupuleti" < > sumanth.pasupuleti...@gmail.com> wrote: > > +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 > roadmap and developers can still make contributions to work unlisted > in the > project roadmap, I think having a project roadmap is certainly a step > in > the right direction. > > Thanks, > Sumanth > > On Mon, Mar 1, 2021 at 1:18 AM Benedict Elliott Smith < > bened...@apache.org> > wrote: > > > 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 resources between > multiple > > entities, as we can signal to each other what our priorities are, > agree to > > prioritise items on the roadmap, and plan cross-organisation capacity > > necessary for each roadmap item. > > > > 2) It signals to the wider user community what to expect, > facilitating > > confidence in project health and direction. I think this will be > > particularly helpful as 4.0 is announced, given the extraordinary > amount of > > time that passed between 3.11 and 4.0. > > > > > > > > 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 don’t think it should lead > to > > work progressing only on roadmap items, but that other major > endeavours > > (i.e. those entailing large impact to the project, or requiring lots > of > > cross-org input) could be put on hold until the earlier roadmap > items were > > properly resourced (or the roadmap revised). > > > > > > > > What do people think? > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
