Re: Project Roadmap
+1 as well. This would be great for the project and for our users. From: Benedict Elliott Smith Sent: Tuesday, March 2, 2021 3:26 AM To: dev@cassandra.apache.org Subject: Re: Project Roadmap Yep, I'm not proposing we start discussions right now. Just wanted to float the idea, see how people felt about it and how people might like it to look procedurally. My only goal is that we have a rough roadmap agreed before GA, to publish alongside any announcement. On 02/03/2021, 09:57, "Benjamin Lerer" wrote: > > 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. I believe that everybody will be in favor of discussing the plans for the next release. We do not really need to commit to anything at this point. My proposal would be to get 4.0-RC out of the door and let a couple of weeks for people to think about the next release. Then we can trigger a discussion for everybody on what they are willing to focus on first. What do you think? Le mar. 2 mars 2021 à 06:29, Berenguer Blasi a écrit : > +1000 on some form of roadmap for visibility and planning > > On 1/3/21 18:35, Benedict Elliott Smith wrote: > > 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 priorities and pressures. > > > > I think the important thing is that in revising the roadmap we'll again > make explicit trade-offs as a community about what we want to invest in > before the next release. > > > > > > On 01/03/2021, 13:26, "Benjamin Lerer" wrote: > > > > 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 discuss how > we > > plan to use CEPs moving forward. > > . > > > > Le lun. 1 mars 2021 à 13:21, Benedict Elliott Smith < > bened...@apache.org> a > > écrit : > > > > > 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 exists I hadn't meant to exclude it, > I more > > > meant that the CEP process is quite involved and spans the > lifetime of the > > > work, and a roadmap helps the project decide on goals irrespective > of a > > > CEP, and helps resource a CEP early in its lifecycle. > > > > > > On 01/03/2021, 11:15, "Mick Semb Wever" wrote: > > > > > > > > > > > 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 approach of the roadmap, > just a > > > visualisation of existing processes, prevents the adding of a > new > > > process > > > to the community. It will also incentivise the thoroughness of > new > > > CEPs. > > > > > > The benefit of having the roadmap as a separate manual process > pre-CEP > > > might save us the cost of creating CEPs that get rejected, but > I can't > > > see > > > that actually being a problem for us. > > > > > > +1 to having the roadmap, in any f
Re: Project Roadmap
Yep, I'm not proposing we start discussions right now. Just wanted to float the idea, see how people felt about it and how people might like it to look procedurally. My only goal is that we have a rough roadmap agreed before GA, to publish alongside any announcement. On 02/03/2021, 09:57, "Benjamin Lerer" wrote: > > 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. I believe that everybody will be in favor of discussing the plans for the next release. We do not really need to commit to anything at this point. My proposal would be to get 4.0-RC out of the door and let a couple of weeks for people to think about the next release. Then we can trigger a discussion for everybody on what they are willing to focus on first. What do you think? Le mar. 2 mars 2021 à 06:29, Berenguer Blasi a écrit : > +1000 on some form of roadmap for visibility and planning > > On 1/3/21 18:35, Benedict Elliott Smith wrote: > > 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 priorities and pressures. > > > > I think the important thing is that in revising the roadmap we'll again > make explicit trade-offs as a community about what we want to invest in > before the next release. > > > > > > On 01/03/2021, 13:26, "Benjamin Lerer" wrote: > > > > 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 discuss how > we > > plan to use CEPs moving forward. > > . > > > > Le lun. 1 mars 2021 à 13:21, Benedict Elliott Smith < > bened...@apache.org> a > > écrit : > > > > > 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 exists I hadn't meant to exclude it, > I more > > > meant that the CEP process is quite involved and spans the > lifetime of the > > > work, and a roadmap helps the project decide on goals irrespective > of a > > > CEP, and helps resource a CEP early in its lifecycle. > > > > > > On 01/03/2021, 11:15, "Mick Semb Wever" wrote: > > > > > > > > > > > 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 approach of the roadmap, > just a > > > visualisation of existing processes, prevents the adding of a > new > > > process > > > to the community. It will also incentivise the thoroughness of > new > > > CEPs. > > > > > > The benefit of having the roadmap as a separate manual process > pre-CEP > > > might save us the cost of creating CEPs that get rejected, but > I can't > > > see > > > that actually being a problem for us. > > > > > > +1 to having the roadmap, in any form. > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org >
Re: Project Roadmap
> > 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. I believe that everybody will be in favor of discussing the plans for the next release. We do not really need to commit to anything at this point. My proposal would be to get 4.0-RC out of the door and let a couple of weeks for people to think about the next release. Then we can trigger a discussion for everybody on what they are willing to focus on first. What do you think? Le mar. 2 mars 2021 à 06:29, Berenguer Blasi a écrit : > +1000 on some form of roadmap for visibility and planning > > On 1/3/21 18:35, Benedict Elliott Smith wrote: > > 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 priorities and pressures. > > > > I think the important thing is that in revising the roadmap we'll again > make explicit trade-offs as a community about what we want to invest in > before the next release. > > > > > > On 01/03/2021, 13:26, "Benjamin Lerer" wrote: > > > > 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 discuss how > we > > plan to use CEPs moving forward. > > . > > > > Le lun. 1 mars 2021 à 13:21, Benedict Elliott Smith < > bened...@apache.org> a > > écrit : > > > > > 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 exists I hadn't meant to exclude it, > I more > > > meant that the CEP process is quite involved and spans the > lifetime of the > > > work, and a roadmap helps the project decide on goals irrespective > of a > > > CEP, and helps resource a CEP early in its lifecycle. > > > > > > On 01/03/2021, 11:15, "Mick Semb Wever" wrote: > > > > > > > > > > > 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 approach of the roadmap, > just a > > > visualisation of existing processes, prevents the adding of a > new > > > process > > > to the community. It will also incentivise the thoroughness of > new > > > CEPs. > > > > > > The benefit of having the roadmap as a separate manual process > pre-CEP > > > might save us the cost of creating CEPs that get rejected, but > I can't > > > see > > > that actually being a problem for us. > > > > > > +1 to having the roadmap, in any form. > > > > > > > > > > > > > - > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > > > > > - > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Project Roadmap
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 priorities and pressures. I think the important thing is that in revising the roadmap we'll again make explicit trade-offs as a community about what we want to invest in before the next release. On 01/03/2021, 13:26, "Benjamin Lerer" wrote: 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 discuss how we plan to use CEPs moving forward. . Le lun. 1 mars 2021 à 13:21, Benedict Elliott Smith a écrit : > 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 exists I hadn't meant to exclude it, I more > meant that the CEP process is quite involved and spans the lifetime of the > work, and a roadmap helps the project decide on goals irrespective of a > CEP, and helps resource a CEP early in its lifecycle. > > On 01/03/2021, 11:15, "Mick Semb Wever" wrote: > > > > > 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 approach of the roadmap, just a > visualisation of existing processes, prevents the adding of a new > process > to the community. It will also incentivise the thoroughness of new > CEPs. > > The benefit of having the roadmap as a separate manual process pre-CEP > might save us the cost of creating CEPs that get rejected, but I can't > see > that actually being a problem for us. > > +1 to having the roadmap, in any form. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > > - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Project Roadmap
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 discuss how we plan to use CEPs moving forward. . Le lun. 1 mars 2021 à 13:21, Benedict Elliott Smith a écrit : > 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 exists I hadn't meant to exclude it, I more > meant that the CEP process is quite involved and spans the lifetime of the > work, and a roadmap helps the project decide on goals irrespective of a > CEP, and helps resource a CEP early in its lifecycle. > > On 01/03/2021, 11:15, "Mick Semb Wever" wrote: > > > > > 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 approach of the roadmap, just a > visualisation of existing processes, prevents the adding of a new > process > to the community. It will also incentivise the thoroughness of new > CEPs. > > The benefit of having the roadmap as a separate manual process pre-CEP > might save us the cost of creating CEPs that get rejected, but I can't > see > that actually being a problem for us. > > +1 to having the roadmap, in any form. > > > > - > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > For additional commands, e-mail: dev-h...@cassandra.apache.org > >
Re: Project Roadmap
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 held position on either (but think it's probably better they're not intrinsically tied in either direction). On 01/03/2021, 12:13, "Benedict Elliott Smith" wrote: 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 exists I hadn't meant to exclude it, I more meant that the CEP process is quite involved and spans the lifetime of the work, and a roadmap helps the project decide on goals irrespective of a CEP, and helps resource a CEP early in its lifecycle. On 01/03/2021, 11:15, "Mick Semb Wever" wrote: > > 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 approach of the roadmap, just a visualisation of existing processes, prevents the adding of a new process to the community. It will also incentivise the thoroughness of new CEPs. The benefit of having the roadmap as a separate manual process pre-CEP might save us the cost of creating CEPs that get rejected, but I can't see that actually being a problem for us. +1 to having the roadmap, in any form. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Project Roadmap
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 exists I hadn't meant to exclude it, I more meant that the CEP process is quite involved and spans the lifetime of the work, and a roadmap helps the project decide on goals irrespective of a CEP, and helps resource a CEP early in its lifecycle. On 01/03/2021, 11:15, "Mick Semb Wever" wrote: > > 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 approach of the roadmap, just a visualisation of existing processes, prevents the adding of a new process to the community. It will also incentivise the thoroughness of new CEPs. The benefit of having the roadmap as a separate manual process pre-CEP might save us the cost of creating CEPs that get rejected, but I can't see that actually being a problem for us. +1 to having the roadmap, in any form. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: Project Roadmap
> > 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 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 > >
Re: Project Roadmap
> > 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 approach of the roadmap, just a visualisation of existing processes, prevents the adding of a new process to the community. It will also incentivise the thoroughness of new CEPs. The benefit of having the roadmap as a separate manual process pre-CEP might save us the cost of creating CEPs that get rejected, but I can't see that actually being a problem for us. +1 to having the roadmap, in any form.
Re: Project Roadmap
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" 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 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
Re: Project Roadmap
+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 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? > >
Project Roadmap
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?
