[tc][all] What should we have as community goals for Y series?( Starting community-wide goals ideas)
Dear all, We're now in R-22 week for Xena cycle which sounds like a perfect time to start calling for community-wide goals ideas for Y-series. According to the goal process schedule [1], we need to find potential goals, and champions before Xena milestone-1 and provide proper discussion in the community right after that to give a clear view and detail on each goal. And if we would like to keep up with the schedule, we should start right away to identify potential goals. So please help to provide ideas for Y series community-wide goals in [2]. Community-wide goals are important in terms of solving and improving a technical area across OpenStack as a whole. It has a lot more benefits to be considered from users as well from a developer's perspective. See [3] for more details about community-wide goals and processes. Also, you can refer to the backlogs of community-wide goals from this[4] and victoria cycle goals[5] (also ussuri[6]). We took cool-down cycle goal step for Xena cycle [7], so no selected goals for Xena. [1] https://governance.openstack.org/tc/goals/#goal-selection-schedule [2] https://etherpad.opendev.org/p/y-series-goals [3] https://governance.openstack.org/tc/goals/index.html [4] https://etherpad.openstack.org/p/community-goals [5] https://etherpad.openstack.org/p/YVR-v-series-goals [6] https://etherpad.openstack.org/p/PVG-u-series-goals [7] https://review.opendev.org/c/openstack/governance/+/770616 *Rico Lin* OIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack
Hello :) Wanted to bring this back to the top of people's inboxes as we are starting to approach Milestone 2 when we want to actually define the goals selected for the next release (Y release). It looks like we only have one goal suggested so far (which is fine; we can only have one goal): Support TLS default in test jobs[1]. That said, we have no goal champion listed for it. We do still have a pretty hefty backlog of alternatives[2] if anyone wanted to step up as champion for one of those at this point. -Kendall (diablo_rojo) [1] https://etherpad.opendev.org/p/y-series-goals [2] https://etherpad.opendev.org/p/community-goals On Tue, May 4, 2021 at 6:10 AM Rico Lin <ricolin@ricolky.com> wrote:
Dear all,
We're now in R-22 week for Xena cycle which sounds like a perfect time to start calling for community-wide goals ideas for Y-series. According to the goal process schedule [1], we need to find potential goals, and champions before Xena milestone-1 and provide proper discussion in the community right after that to give a clear view and detail on each goal. And if we would like to keep up with the schedule, we should start right away to identify potential goals.
So please help to provide ideas for Y series community-wide goals in [2].
Community-wide goals are important in terms of solving and improving a technical area across OpenStack as a whole. It has a lot more benefits to be considered from users as well from a developer's perspective. See [3] for more details about community-wide goals and processes.
Also, you can refer to the backlogs of community-wide goals from this[4] and victoria cycle goals[5] (also ussuri[6]). We took cool-down cycle goal step for Xena cycle [7], so no selected goals for Xena.
[1] https://governance.openstack.org/tc/goals/#goal-selection-schedule [2] https://etherpad.opendev.org/p/y-series-goals [3] https://governance.openstack.org/tc/goals/index.html [4] https://etherpad.openstack.org/p/community-goals [5] https://etherpad.openstack.org/p/YVR-v-series-goals [6] https://etherpad.openstack.org/p/PVG-u-series-goals [7] https://review.opendev.org/c/openstack/governance/+/770616
*Rico Lin* OIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack
On 2021-06-28 14:25:12 -0700 (-0700), Kendall Nelson wrote: [...]
the next release (Y release).
You gave me a scare, but... *phew* that's the release after next. We haven't released Xena yet!
It looks like we only have one goal suggested so far (which is fine; we can only have one goal) [...]
Can we only have one goal? Or can we have only one goal? I assume you mean the latter, but they're definitely different things. -- Jeremy Stanley
On Mon, Jun 28, 2021 at 2:40 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2021-06-28 14:25:12 -0700 (-0700), Kendall Nelson wrote: [...]
the next release (Y release).
You gave me a scare, but... *phew* that's the release after next. We haven't released Xena yet!
It looks like we only have one goal suggested so far (which is fine; we can only have one goal) [...]
Can we only have one goal? Or can we have only one goal? I assume you mean the latter, but they're definitely different things. -- Jeremy Stanley
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.
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! -- Thierry
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
On Tue, Jun 29, 2021 at 6:45 AM Sean Mooney <smooney@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.
On Tue, Jun 29, 2021 at 6:36 AM Julia Kreger <juliaashleykreger@gmail.com> wrote:
I have a crazy idea!
I love crazy ideas
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.
What we can do is to ask projects to provide their *most* painful operator perceived performance or experience issue as pre-select goal survey for the first step and then calling for help or mark it as a goal for the Y cycle as the second step. IMO, marking the pre-select goal is exactly to checking if any goal material can be actually a goal. So I think going ahead and raise such activity makes sense. We can discuss this more in our next TC meeting if anyone also interested.
OooOOOo I like this idea! Would be super awesome to get a list of all the worst, most painful issues and then fix them :) -Kendall On Mon, Jun 28, 2021 at 3:32 PM Julia Kreger <juliaashleykreger@gmail.com> wrote:
On Mon, Jun 28, 2021 at 2:40 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2021-06-28 14:25:12 -0700 (-0700), Kendall Nelson wrote: [...]
the next release (Y release).
You gave me a scare, but... *phew* that's the release after next. We haven't released Xena yet!
It looks like we only have one goal suggested so far (which is fine; we can only have one goal) [...]
Can we only have one goal? Or can we have only one goal? I assume you mean the latter, but they're definitely different things. -- Jeremy Stanley
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 also suspect there may be some commonality between projects, and listening/enumerating them does help raise cross-project visibility. "Hey, those crazy ironic people did xyz and are getting amazing performance as a result. Did we make the same mistake!?!? Can we follow the same basic pattern?" On Tue, Jun 29, 2021 at 11:28 AM Kendall Nelson <kennelson11@gmail.com> wrote:
OooOOOo I like this idea! Would be super awesome to get a list of all the worst, most painful issues and then fix them :)
-Kendall
On Mon, Jun 28, 2021 at 3:32 PM Julia Kreger <juliaashleykreger@gmail.com> wrote:
On Mon, Jun 28, 2021 at 2:40 PM Jeremy Stanley <fungi@yuggoth.org> wrote:
On 2021-06-28 14:25:12 -0700 (-0700), Kendall Nelson wrote: [...]
the next release (Y release).
You gave me a scare, but... *phew* that's the release after next. We haven't released Xena yet!
It looks like we only have one goal suggested so far (which is fine; we can only have one goal) [...]
Can we only have one goal? Or can we have only one goal? I assume you mean the latter, but they're definitely different things. -- Jeremy Stanley
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.
On Tue, Jun 29, 2021 at 2:49 PM Julia Kreger <juliaashleykreger@gmail.com> wrote:
I also suspect there may be some commonality between projects, and listening/enumerating them does help raise cross-project visibility. "Hey, those crazy ironic people did xyz and are getting amazing performance as a result. Did we make the same mistake!?!? Can we follow the same basic pattern?"
On Tue, Jun 29, 2021 at 11:28 AM Kendall Nelson <kennelson11@gmail.com> wrote:
OooOOOo I like this idea! Would be super awesome to get a list of all
the worst, most painful issues and then fix them :)
-Kendall
On Mon, Jun 28, 2021 at 3:32 PM Julia Kreger <
juliaashleykreger@gmail.com> wrote:
On Mon, Jun 28, 2021 at 2:40 PM Jeremy Stanley <fungi@yuggoth.org>
wrote:
On 2021-06-28 14:25:12 -0700 (-0700), Kendall Nelson wrote: [...]
the next release (Y release).
You gave me a scare, but... *phew* that's the release after next. We haven't released Xena yet!
It looks like we only have one goal suggested so far (which is fine; we can only have one goal) [...]
Can we only have one goal? Or can we have only one goal? I assume you mean the latter, but they're definitely different things. -- Jeremy Stanley
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 think the featuritis of end consumers / vendors is starting to dwindle, and a focus on making the software we have work extremely well (not saying it doesn't now) is a very admirable goal. So I think theJulia is spot on. -- ~/DonnyD C: 805 814 6800 "No mission too difficult. No sacrifice too great. Duty First"
I like Julia's idea alot as an ex-operator. I would also like to propose maybe starting to target some aspects of the Inclusive Naming initiative? Even if it's the projects just reviewing where they are at and starting to plan changes to meet this initiative? Amy (spotz) On Tue, Jun 29, 2021 at 2:11 PM Donny Davis <donny@fortnebula.com> wrote:
On Tue, Jun 29, 2021 at 2:49 PM Julia Kreger <juliaashleykreger@gmail.com> wrote:
I also suspect there may be some commonality between projects, and listening/enumerating them does help raise cross-project visibility. "Hey, those crazy ironic people did xyz and are getting amazing performance as a result. Did we make the same mistake!?!? Can we follow the same basic pattern?"
On Tue, Jun 29, 2021 at 11:28 AM Kendall Nelson <kennelson11@gmail.com> wrote:
OooOOOo I like this idea! Would be super awesome to get a list of all
the worst, most painful issues and then fix them :)
-Kendall
On Mon, Jun 28, 2021 at 3:32 PM Julia Kreger <
juliaashleykreger@gmail.com> wrote:
On Mon, Jun 28, 2021 at 2:40 PM Jeremy Stanley <fungi@yuggoth.org>
wrote:
On 2021-06-28 14:25:12 -0700 (-0700), Kendall Nelson wrote: [...]
the next release (Y release).
You gave me a scare, but... *phew* that's the release after next. We haven't released Xena yet!
It looks like we only have one goal suggested so far (which is fine; we can only have one goal) [...]
Can we only have one goal? Or can we have only one goal? I assume you mean the latter, but they're definitely different things. -- Jeremy Stanley
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 think the featuritis of end consumers / vendors is starting to dwindle, and a focus on making the software we have work extremely well (not saying it doesn't now) is a very admirable goal.
So I think theJulia is spot on. -- ~/DonnyD C: 805 814 6800 "No mission too difficult. No sacrifice too great. Duty First"
On 6/29/2021 1:28 PM, Kendall Nelson wrote:
OooOOOo I like this idea! Would be super awesome to get a list of all the worst, most painful issues and then fix them :)
-Kendall
I like this idea as well. I know that Cinder has some things that can/should be put on the list. --Jay
On Mon, Jun 28, 2021 at 3:32 PM Julia Kreger <juliaashleykreger@gmail.com <mailto:juliaashleykreger@gmail.com>> wrote:
On Mon, Jun 28, 2021 at 2:40 PM Jeremy Stanley <fungi@yuggoth.org <mailto:fungi@yuggoth.org>> wrote: > > On 2021-06-28 14:25:12 -0700 (-0700), Kendall Nelson wrote: > [...] > > the next release (Y release). > > You gave me a scare, but... *phew* that's the release after next. We > haven't released Xena yet! > > > It looks like we only have one goal suggested so far (which is > > fine; we can only have one goal) > [...] > > Can we only have one goal? Or can we have only one goal? I assume > you mean the latter, but they're definitely different things. > -- > Jeremy Stanley
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.
---- On Mon, 28 Jun 2021 16:25:12 -0500 Kendall Nelson <kennelson11@gmail.com> wrote ----
Hello :)
Wanted to bring this back to the top of people's inboxes as we are starting to approach Milestone 2 when we want to actually define the goals selected for the next release (Y release). It looks like we only have one goal suggested so far (which is fine; we can only have one goal): Support TLS default in test jobs[1]. That said, we have no goal champion listed for it.
We do still have a pretty hefty backlog of alternatives[2] if anyone wanted to step up as champion for one of those at this point.
I have added the secure RBAC as one of the candidate in etherpad. I will compose the goal this or next week early. -gmann
-Kendall (diablo_rojo)[1] https://etherpad.opendev.org/p/y-series-goals[2] https://etherpad.opendev.org/p/community-goals
On Tue, May 4, 2021 at 6:10 AM Rico Lin <ricolin@ricolky.com> wrote: Dear all, We're now in R-22 week for Xena cycle which sounds like a perfect time to start calling for community-wide goals ideas for Y-series. According to the goal process schedule [1], we need to find potential goals, and champions before Xena milestone-1 and provide proper discussion in the community right after that to give a clear view and detail on each goal. And if we would like to keep up with the schedule, we should start right away to identify potential goals. So please help to provide ideas for Y series community-wide goals in [2]. Community-wide goals are important in terms of solving and improving a technical area across OpenStack as a whole. It has a lot more benefits to be considered from users as well from a developer's perspective. See [3] for more details about community-wide goals and processes.
Also, you can refer to the backlogs of community-wide goals from this[4] and victoria cycle goals[5] (also ussuri[6]). We took cool-down cycle goal step for Xena cycle [7], so no selected goals for Xena.
[1] https://governance.openstack.org/tc/goals/#goal-selection-schedule [2] https://etherpad.opendev.org/p/y-series-goals [3] https://governance.openstack.org/tc/goals/index.html [4] https://etherpad.openstack.org/p/community-goals [5] https://etherpad.openstack.org/p/YVR-v-series-goals[6] https://etherpad.openstack.org/p/PVG-u-series-goals[7] https://review.opendev.org/c/openstack/governance/+/770616 Rico LinOIF Board director, OpenStack TC, Multi-arch SIG chair, Heat PTL, Senior Software Engineer@EasyStack
participants (10)
-
Amy Marrich
-
Donny Davis
-
Ghanshyam Mann
-
Jay Bryant
-
Jeremy Stanley
-
Julia Kreger
-
Kendall Nelson
-
Rico Lin
-
Sean Mooney
-
Thierry Carrez