On Thu, Dec 15, 2016 at 10:58 AM, Sean Dague <[email protected]> wrote: > One of the big things to consider is which of these items directly > support one of the key PWG issues: "painless upgrades" > > The following items: movinging paste.ini out of config, new style > olso.policy (in code), and rootwrap -> privsep all eliminate files in > /etc that dramatically impact code execution, and need careful merging > during upgrades. > > These are kind of the trifecta of content that really never should have > been in /etc, except it was easy to hack out in an initial version. > > So, it may not be evident to users that this is what's getting in the > way of features rolling out to them, or them being 2 to 3 releases > behind master, it's a huge part of it. As such, I think any/all of them > should be considered as top level item for the next round of priorities. >
Yep -- this is the heart of the comms difficulty with these goals. I struggled myself to understand why there were perceived "tech debt" items high on the list. I had to have the cascading need explained to me that got the end user outcome from the goal. So, adding that additional context to the goal proposals helps. Anne > > I'd argue that until upgrades become really easy, everything else is > pretty secondary, because if people don't upgrade they'll never get any > of the other enhancements you are making. > > On 12/15/2016 04:11 AM, Jean-Philippe Evrard wrote: > > Hello, > > > > Maybe this will sound dumb … > > > > I received this email on openstack-dev mailing list. I don’t know if it > was sent to any other place, because it’s basically agreeing on development > to be done, which makes sense to me. > > So openstack-dev people (called further “devs”) will push their company > agenda on these goals based on what they know in their company. I see the > work done together there, and I find it great, but… > > > > Wouldn’t that be better if we open this discussion to the general > population (openstack users, operators, and devs) instead of just devs? > > I submit this question because what I see on https://etherpad.openstack. > org/p/community-goals is not only tech debt items that we have to fix, > but also ideas of improvement on the long run for our users. > > It makes sense to me to keep the tech debt items as a devs only topic (I > don’t see why a user cares _at least at first_ about using oslo.privsep vs > oslo.rootwrap), and it makes also sense to me to align “community goals” > with the broad community. > > > > What do you think? Should we remove the non tech-debt items in this > dev-community-goals etherpad? > > Should we have another set of community goals that could serve as a > basis for the OpenStack user survey? > > Or should we keep these goals merged together, with the risk of having > tech-debt items having lower priority the user requirements? (For that, the > TC would be a good judge for final cycle prioritization) > > > > I think having community goals is great for openstack, and I’d be happy > to understand how we’ll adapt http://governance.openstack. > org/goals/index.html into real life work usable for everyone. > > > > Thanks for your clarifications. > > > > Best regards, > > Jean-Philippe Evrard > > > > > > On 12/12/2016, 12:19, "Emilien Macchi" <[email protected]> wrote: > > > > On Tue, Nov 29, 2016 at 7:39 PM, Emilien Macchi <[email protected]> > wrote: > > > A few months ago, our community started to find and work on > > > OpenStack-wide goals to "achieve visible common changes, push for > > > basic levels of consistency and user experience, and efficiently > > > improve certain areas where technical debt payments have become too > > > high – across all OpenStack projects". > > > > > > http://governance.openstack.org/goals/index.html > > > > > > We started to define a first Goal in Ocata (Remove Copies of > Incubated > > > Oslo Code) and we would like to move forward in Pike. > > > I see 3 actions we could take now: > > > > > > 1) Collect feedback of our first iteration of Community Goals in > > > OpenStack during Ocata. What went well? What was more challenging? > > > > > > Some examples: > > > - should we move the goal documents into a separate repo to allow a > > > shorter review time, where we could just have 2 TC members approve > > > them instead of waiting a week? > > > - we expected all teams to respond to all goals, even if they > have no > > > work to do. Should we continue that way? > > > - should we improve the guidance to achieve Goals? > > > > > > I created an etherpad if folks want to give feedback: > > > https://etherpad.openstack.org/p/community-goals-ocata-feedback > > > > > > 2) Goals backlog - https://etherpad.openstack. > org/p/community-goals > > > - new Goals are highly welcome. > > > - each Goal would be achievable in one cycle, if not I think we > need > > > to break it down into separated Goals (with connections). > > > - some Goals already have a team (ex: Python 3) but some haven't. > > > Maybe could we dress a list of people able to step-up and > volunteer to > > > help on these ones. > > > - some Goals might require some documentation for how to achieve > it. > > > > > > I think for now 2) can be discussed on the etherpad, though feel > free > > > to propose another channel. > > > > > > 3) Choose Goals for Pike. > > > Some of us already did, but we might want to start looking at what > > > Goals we would like to achieve during Pike cycle. > > > I was thinking at giving a score to the Goals, that could be > > > calculated by its priority (I know it's vague but we know what is > > > really urgent for us versus what can wait 6 months); but also the > > > number of people who are interested to contribute on a Goal (if > this > > > Goal doesn't have a team yet). > > > For now, openstack/governance is the repository for Goals, please > > > propose them here. > > > > > > > > > Please give feedback, we're doing iterations here, and hopefully > we'll > > > improve our Community Goals over the next cycles. > > > Thanks for your time, > > > > Two weeks happened, here's a digest version of the etherpad: > > > > - Most of projects achieved the goal for Ocata, and we saw strong > > interest to do it on time > > - Some confusion between the ACK'ing of a goal, and actually doing > the work. > > - Some projects were slow on the uptake (of starting the work) and > > even reviewing the patches. > > - For now, keep using openstack/governance repo for documenting > Goals. > > - Improve guidance on what projects are expected to do when updating > > the status of the Goal. > > - For each Goal, document who the "guides" are and how to find them > > when help is needed. > > - It seems like achieving multiple Goals in a single cycle wouldn't > be > > possible for all teams, we could prioritize them to let teams achieve > > more than one Goal within a cycle. > > > > What's next? > > https://etherpad.openstack.org/p/community-goals > > Now that we have a good set of Goals that are proposed in this > > etherpad, we might want to rank them by priority (1 is the most > > important). Feel free to do it in the etherpad, by putting a rank in > > "Priority rank". > > > > Also, I've noticed some Goals might be too big to be achievable > within > > a single cycle and might need to be split (Rolling upgrades for > > example). If you're author of one these goals, please do so. > > I hope we can start defining Pike Goals by next week, so we can start > > documenting what we would expect and the guidance to achieve it/them. > > > > Any feedback is welcome, > > -- > > Emilien Macchi > > > > ____________________________________________________________ > ______________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected]?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > > > ________________________________ > > Rackspace Limited is a company registered in England & Wales (company > registered number 03897010) whose registered office is at 5 Millington > Road, Hyde Park Hayes, Middlesex UB3 4AZ. Rackspace Limited privacy policy > can be viewed at www.rackspace.co.uk/legal/privacy-policy - This e-mail > message may contain confidential or privileged information intended for the > recipient. Any dissemination, distribution or copying of the enclosed > material is prohibited. If you receive this transmission in error, please > notify us immediately by e-mail at [email protected] and delete the > original message. Your cooperation is appreciated. > > ____________________________________________________________ > ______________ > > OpenStack Development Mailing List (not for usage questions) > > Unsubscribe: [email protected]?subject: > unsubscribe > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > -- > Sean Dague > http://dague.net > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Anne Gentle -- Read my blog: justwrite.click <https://justwriteclick.com> Subscribe to Docs|Code: docslikecode.com
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
