[tc][all] What should we have as community goals for Y series?( Starting community-wide goals ideas)

Julia Kreger juliaashleykreger at gmail.com
Tue Jun 29 13:58:57 UTC 2021


On Tue, Jun 29, 2021 at 6:45 AM Sean Mooney <smooney at redhat.com> wrote:
>
> On Tue, 2021-06-29 at 12:31 +0200, Thierry Carrez wrote:
> > Julia Kreger wrote:
> > > I have a crazy idea!
> > >
> > > What if instead of a common singular goal to uniformly raise the bar
> > > across projects, we have each project work on their *most* painful
> > > operator perceived performance or experience issue and attempt to try
> > > and eliminate the issue or perception? And where cross-project
> > > integrations are involved, other projects could put review priority on
> > > helping get fixes or improvements pushed forward to address such
> > > operator experiences.
> > >
> > > Such an effort would take a dramatically different appearance by
> > > project, and would really require each project to identify a known
> > > issue, and then to report it back along with the gain they yielded
> > > from the effort. Of course, to get there, projects would also have to
> > > ensure that they could somehow measure the impact of their changes to
> > > remedy such an issue.
> >
> > I like that!
>
> i was going to suggest something similar.
> we had talked about dedicated the xena or wallaby release in light of world events
> to take a step back and have a stablisation release wehre we focused less on feature
> development and workd on tech debt and basically slowed down developemtn to acount for
> the stress and other pressures people were under.
>
> unfortunetly at least for nova that never happened. im not sure about other project but
> i really like the idea of have a stablisation release where project focus on fixint
> the pain points of operators  rahter then on enabling shiny feature X
> >
>

I think we, as a community, are very much long due for something such
as this.  We've got technical debt to pay down. We've got bugs to be
fixed. I suspect most of the older projects know exactly where their
pain points are already, just because of the need for features,
efforts to work on them get put in a back seat or minimal review
attention.

Perceptions are important, and shiny features are shiny features. If
the operator frustration outweighs the value of the shiny feature,
then off to another product someone will go.

>
>



More information about the openstack-discuss mailing list