Proposal: Add criteria for graduating projects to publish a 6 month product roadmap #174
Comments
|
SGTM
This should arguably be covered by the CII Best Practises Program
<https://bestpractices.coreinfrastructure.org/en>, which is a requirement
for CNCF graduation. If not, we should fill the gap, IMO.
Q
…On Mon, Nov 26, 2018 at 9:55 AM Cheryl J. Hung ***@***.***> wrote:
I spoke to a Kubernetes end user company who are currently planning their
2019 technical architecture. The CTO asked me whether projects had feature
roadmaps for the next six months - one year which they can incorporate into
their planning. They are a small company with four infrastructure
engineers, so lack the time to engage directly with each project.
I propose that the graduation criteria should require projects to publish
a six month feature roadmap. This provides visibility for planning and also
allows users to give early feedback. The format could be a simple file in
Github.
Feedback and thoughts are very welcome. @caniszczyk
<https://github.com/caniszczyk> @monadic <https://github.com/monadic>
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#174>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/ApoAeFe3hmRgdgwiYrI03CSvaCZzc6Ijks5uzCsUgaJpZM4YziKu>
.
--
Quinton Hoole
quinton@hoole.biz
|
|
I do think that roadmaps are a good idea and a best practice in general, but there are also projects for which roadmaps make less sense, particularly for projects that are essentially specifications or have a heavy specification component. CNI, TUF, SPIFFE, OpenMetrics, CloudEvents, and to a lesser extent OpenTracing are existing CNCF projects that fit this bill. I would argue for relaxing any hypothetical roadmap requirement for "spec" projects, as stability and lack of feature turnover can be hallmarks of project strength. |
|
I think that having a roadmap that says "we have no roadmap and here's why"
is a good way to deal with that.
Co-incidentally, that's exactly what CII does:
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/roadmap.md
Q
…On Mon, Nov 26, 2018 at 5:14 PM Luc Perkins ***@***.***> wrote:
I do think that roadmaps are a good idea and a best practice *in general*,
but there are also projects for which roadmaps make less sense,
particularly for projects that are essentially specifications or have a
heavy specification component. CNI, TUF, SPIFFE, OpenMetrics, and
CloudEvents are existing CNCF projects that fit this bill.
I would argue for relaxing any hypothetical roadmap requirement for "spec"
projects, as stability and lack of feature turnover can be hallmarks of
project strength.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#174 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ApoAeGMdKSCArCxWA3tKpMttsxDAxjmbks5uzJIPgaJpZM4YziKu>
.
--
Quinton Hoole
quinton@hoole.biz
|
|
Thanks @quinton-hoole @lucperkins for the feedback. I agree that a roadmap for a specification project can explicitly state that there are no planned upcoming changes. Any other feedback, or shall we add it as an agenda item to a future TOC meeting? |
|
I don't think it's our business to tell open source projects that they need
to put roadmaps out for the benefit of end users. It's nice if they do, but
that seems like a rather excessive requirement that is far beyond what I've
seen from not-for-profit open source anywhere else.
…On Tue, Nov 27, 2018 at 8:08 AM Cheryl J. Hung ***@***.***> wrote:
Thanks @quinton-hoole <https://github.com/quinton-hoole> @lucperkins
<https://github.com/lucperkins> for the feedback. I agree that a roadmap
for a specification project can explicitly state that there are no planned
upcoming changes.
Any other feedback, or shall we add it as an agenda item to a future TOC
meeting?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#174 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAlGknX6tALgqeNLwDeuljWuLczd8h7Jks5uzTk5gaJpZM4YziKu>
.
|
|
Right, it could never be a requirement for all open source projects, but would you say that "Graduation" implies enough maturity for people to plan six months ahead? |
|
No, I wouldn't.
…On Wed, Nov 28, 2018 at 1:58 PM Cheryl J. Hung ***@***.***> wrote:
Right, it could never be a requirement for all open source projects, but
would you say that "Graduation" implies enough maturity for people to plan
six months ahead?
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#174 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAlGkt3vmZnzD_HDiYzpNBOVUcqrEHylks5uztzlgaJpZM4YziKu>
.
|
|
Camille, could you expand a bit on your objections to making a roadmap a
requirement for graduation. I want to make sure I understand the crux of
your objections. I've heard "rather excessive" and "far beyond other OSS
projects", but I sense that there's more?
Playing the devils advocate for the moment, if we're telling users that
they can "bet the farm" on graduated projects, and projects are seeing
significant value in being promoted as such, then a basic roadmap does't
seem self-evidently excessive?
Q
On Wed, Nov 28, 2018 at 11:04 AM Camille Fournier <notifications@github.com>
wrote:
… No, I wouldn't.
On Wed, Nov 28, 2018 at 1:58 PM Cheryl J. Hung ***@***.***>
wrote:
> Right, it could never be a requirement for all open source projects, but
> would you say that "Graduation" implies enough maturity for people to
plan
> six months ahead?
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#174 (comment)>, or mute
> the thread
> <
https://github.com/notifications/unsubscribe-auth/AAlGkt3vmZnzD_HDiYzpNBOVUcqrEHylks5uztzlgaJpZM4YziKu
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#174 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ApoAeGszTIqmHtg18uKZwHEdtaSy36KLks5uzt5FgaJpZM4YziKu>
.
--
Quinton Hoole
quinton@hoole.biz
|
|
I guess in general I don't put much stock in project roadmaps 6 months out,
having seen even vendors barely capable of delivering anything reliable on
them, and knowing in excruciating detail the challenges in software project
planning. Furthermore, we are an open source foundation, NOT a vendor
software provider. I'm very reluctant to add a level of what I would
consider to be sales-y bureaucracy onto projects that are supposed to be
somewhat more self-governing and open.
This is the kind of thing that I might expect from a vendored version of an
open source project, but not necessarily from the open source project
itself, if that makes sense. I'd be very interested in hearing from our
graduated projects as to how they would feel about providing roadmap
commitments 6 months out. But this all just feels very anti-open source to
me, favoring projects with large professional funding behind them, which is
not the only projects I would hope we're encouraging.
On Wed, Nov 28, 2018 at 3:14 PM Quinton Hoole <notifications@github.com>
wrote:
… Camille, could you expand a bit on your objections to making a roadmap a
requirement for graduation. I want to make sure I understand the crux of
your objections. I've heard "rather excessive" and "far beyond other OSS
projects", but I sense that there's more?
Playing the devils advocate for the moment, if we're telling users that
they can "bet the farm" on graduated projects, and projects are seeing
significant value in being promoted as such, then a basic roadmap does't
seem self-evidently excessive?
Q
On Wed, Nov 28, 2018 at 11:04 AM Camille Fournier <
***@***.***>
wrote:
> No, I wouldn't.
>
> On Wed, Nov 28, 2018 at 1:58 PM Cheryl J. Hung ***@***.***
>
> wrote:
>
> > Right, it could never be a requirement for all open source projects,
but
> > would you say that "Graduation" implies enough maturity for people to
> plan
> > six months ahead?
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub
> > <#174 (comment)>, or
mute
> > the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/AAlGkt3vmZnzD_HDiYzpNBOVUcqrEHylks5uztzlgaJpZM4YziKu
> >
> > .
> >
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#174 (comment)>, or mute
> the thread
> <
https://github.com/notifications/unsubscribe-auth/ApoAeGszTIqmHtg18uKZwHEdtaSy36KLks5uzt5FgaJpZM4YziKu
>
> .
>
--
Quinton Hoole
***@***.***
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#174 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAlGkkty66CBudyVVRE09-vmj3FVZkgFks5uzu6YgaJpZM4YziKu>
.
|
|
Aah, that makes sense and, on second thoughts, I do share most of your
concerns.
I'm going to amend my position on this to "nice to have" rather than a
requirement, for the reasons you mention.
Q
On Wed, Nov 28, 2018 at 12:25 PM Camille Fournier <notifications@github.com>
wrote:
… I guess in general I don't put much stock in project roadmaps 6 months out,
having seen even vendors barely capable of delivering anything reliable on
them, and knowing in excruciating detail the challenges in software project
planning. Furthermore, we are an open source foundation, NOT a vendor
software provider. I'm very reluctant to add a level of what I would
consider to be sales-y bureaucracy onto projects that are supposed to be
somewhat more self-governing and open.
This is the kind of thing that I might expect from a vendored version of an
open source project, but not necessarily from the open source project
itself, if that makes sense. I'd be very interested in hearing from our
graduated projects as to how they would feel about providing roadmap
commitments 6 months out. But this all just feels very anti-open source to
me, favoring projects with large professional funding behind them, which is
not the only projects I would hope we're encouraging.
On Wed, Nov 28, 2018 at 3:14 PM Quinton Hoole ***@***.***>
wrote:
> Camille, could you expand a bit on your objections to making a roadmap a
> requirement for graduation. I want to make sure I understand the crux of
> your objections. I've heard "rather excessive" and "far beyond other OSS
> projects", but I sense that there's more?
>
> Playing the devils advocate for the moment, if we're telling users that
> they can "bet the farm" on graduated projects, and projects are seeing
> significant value in being promoted as such, then a basic roadmap does't
> seem self-evidently excessive?
>
> Q
>
>
> On Wed, Nov 28, 2018 at 11:04 AM Camille Fournier <
> ***@***.***>
> wrote:
>
> > No, I wouldn't.
> >
> > On Wed, Nov 28, 2018 at 1:58 PM Cheryl J. Hung <
***@***.***
> >
> > wrote:
> >
> > > Right, it could never be a requirement for all open source projects,
> but
> > > would you say that "Graduation" implies enough maturity for people to
> > plan
> > > six months ahead?
> > >
> > > —
> > > You are receiving this because you commented.
> > > Reply to this email directly, view it on GitHub
> > > <#174 (comment)>, or
> mute
> > > the thread
> > > <
> >
>
https://github.com/notifications/unsubscribe-auth/AAlGkt3vmZnzD_HDiYzpNBOVUcqrEHylks5uztzlgaJpZM4YziKu
> > >
> > > .
> > >
> >
> > —
> > You are receiving this because you commented.
> > Reply to this email directly, view it on GitHub
> > <#174 (comment)>, or
mute
> > the thread
> > <
>
https://github.com/notifications/unsubscribe-auth/ApoAeGszTIqmHtg18uKZwHEdtaSy36KLks5uzt5FgaJpZM4YziKu
> >
> > .
> >
>
>
> --
> Quinton Hoole
> ***@***.***
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <#174 (comment)>, or mute
> the thread
> <
https://github.com/notifications/unsubscribe-auth/AAlGkkty66CBudyVVRE09-vmj3FVZkgFks5uzu6YgaJpZM4YziKu
>
> .
>
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#174 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ApoAeNOG5FvCjErPaPljm4m-hLghticxks5uzvFMgaJpZM4YziKu>
.
--
Quinton Hoole
quinton@hoole.biz
|
|
Closing for now; I will send a writeup about end user needs to the TOC mailing list next week. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
I spoke to a Kubernetes end user company who are currently planning their 2019 technical architecture. The CTO asked me whether projects had feature roadmaps for the next six months - one year which they can incorporate into their planning. They are a small company with four infrastructure engineers, so lack the time to engage directly with each project.
I propose that the graduation criteria should require projects to publish a six month feature roadmap. This provides visibility for planning and also allows users to give early feedback. The format could be a simple file in Github.
Feedback and thoughts are very welcome. @caniszczyk @monadic
The text was updated successfully, but these errors were encountered: