Re: [openstack-dev] [all] Stepping down from Release Management team

[Shamail Tahir]

> On Oct 8, 2018, at 2:34 PM, Doug Hellmann  wrote:
> 
> Anne Bertucio  writes:
> 
>> Hi all,
>> 
>> I have had a fantastic time getting to work on the Release Management
>> team and getting to know you all through the release marketing work,
>> however, it is time for me to step down from my role on the Release
>> Management team as I am moving on from my role at the Foundation and
>> will no longer be working on upstream OpenStack. I cannot thank you
>> all enough for how you all welcomed me into the OpenStack community
>> and for how much I have learned about open source development in my
>> time here.
>> 
>> If you have questions about cycle-highlights, swing by #openstack-release. 
>> If you have questions about release marketing, contact lau...@openstack.org.
>> For other inquiries, contact alli...@openstack.org. 
>> While I won't be working upstream anymore, I'll only be a Tweet or IRC 
>> message away. 
>> 
>> Thank you again, and remember that cycle-highlights should be
>> submitted by RC1.
> 
> Thank you for everything, Anne! The cycle-highlights system you helped
> us create is a great example of using decentralization and peer review
> at the same time. I'm sure it's going to continue to be an important
> communication tool for the community.
+1

It was a pleasure working with you Anne! Thanks for everything you helped 
accomplish through your contributions to the community. I wish you success in 
your next adventure.

> 
> Doug
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [tc] [election] NON nomination for TC

[Shamail Tahir]

> On Oct 3, 2017, at 8:16 AM, Thierry Carrez  wrote:
> 
> Sean Dague wrote:
>> I'd like to announce that after 4 years serving on the OpenStack
>> Technical Committee, I will not be running in this fall's
>> election. Over the last 4 years we've navigated some rough seas
>> together, including the transition to more inclusion of projects, the
>> dive off the hype curve, the emergence of real interoperability
>> between clouds, and the beginnings of a new vision of OpenStack
>> pairing with more technologies beyond our community.
>> 
>> There remains a ton of good work to be done. But it's also important
>> that we have a wide range of leaders to do that. Those opportunities
>> only exist if we make space for new leaders to emerge. Rotational
>> leadership is part of what makes OpenStack great, and is part of what
>> will ensure that this community lasts far beyond any individuals
>> within it.
>> 
>> I plan to still be around in the community, and contribute where
>> needed. So this is not farewell. However it will be good to see new
>> faces among the folks leading the next steps in the community.
>> 
>> I would encourage all members of the community that are interested in
>> contributing to the future of OpenStack to step forward and run. It's
>> important to realize what the TC is and can be. This remains a
>> community driven by consensus, and the TC reflects that. Being a
>> member of the TC does raise your community visibility, but it does not
>> replace the need to listen, understand, communicate clearly, and
>> realize that hard work comes through compromise.
>> 
>> Good luck to all our candidates this fall, and thanks for letting me
>> represent you the past 4 years.
> 
> Thanks Sean for your service on the TC.
> 
> Your experience and knowledge of open source development dynamics will
> be missed ! I really appreciated your insights and grounded perspective
> in difficult governance discussions that we had to navigate together. I
> hope you'll still be able to weigh in on some of those, even if you
> won't participate in formal votes anymore.
+1

Thank you for demonstrating leadership through your actions. We really 
appreciated your involvement in ops meetups and actively asking for user 
feedback.
> 
> Cheers,
> 
> -- 
> Thierry Carrez (ttx)
> 
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Sydney Forum Topic Submission

[Shamail Tahir]

Hi,

We have made it to the next stage of the topic selection process for the
Forum in Sydney!

At the Forum the entire OpenStack community (users and developers) gathers
to brainstorm the requirements for the next release, gather feedback on the
past version and have strategic discussions that go beyond just one release
cycle. The Sydney Forum is the start of the Rocky release cycle. Please
prepare session ideas with feedback from the Pike release in mind.

Our submission tool is now open for you to submit abstracts for the most
popular sessions that came out of your brainstorming.

Ask all session leaders to submit their abstracts at:
http://forumtopics.openstack.org/

before *11:59PM UTC on Friday September 29th*!

We are looking for a good mix of project-specific, cross-project or
strategic/whole-of-community discussions, and sessions that emphasize
collaboration between users and developers are most welcome!

We assume that anything submitted to the Forum Topics Tool has achieved a
good amount of discussion and consensus that it's a worthwhile topic. After
submissions close, a team of representatives from the User Committee, the
Technical Committee, and Foundation staff will take the sessions proposed
by the community and fill out the schedule.

You can expect the draft schedule to be released on October 9th, 2017.

Further details about the Forum can be found at:
https://wiki.openstack.org/wiki/Forum

Regards,
User Committee/Technical Committee
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Forum Topic Submission

[Shamail Tahir]

Hi Forum Brainstormers,

Wow! Some great topics in the etherpads so far. This event is going to be
amazing.

We're less than a week away now from opening the "formal submission" part
of the process.

If you haven't already, please start prioritizing the top sessions from
your list of ideas. Starting next week, the formal submission will ask for
a written abstract, and one or more session leaders for each session you
want to submit.

Late to the party? Check out the topic brainstorming at:
*https://wiki.openstack.org/wiki/Forum/Sydney2017*


and on a mailing list near you!

Thanks,
User Committee/Technical Committee
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

[Shamail Tahir]

On Wed, Jun 21, 2017 at 12:02 PM, Thierry Carrez <thie...@openstack.org>
wrote:

> Shamail Tahir wrote:
> > In the past, governance has helped (on the UC WG side) to reduce
> > overlaps/duplication in WGs chartered for similar objectives. I would
> > like to understand how we will handle this (if at all) with the new SIG
> > proposa?
>
> I tend to think that any overlap/duplication would get solved naturally,
> without having to force everyone through an application process that may
> discourage natural emergence of such groups. I feel like an application
> process would be premature optimization. We can always encourage groups
> to merge (or clean them up) after the fact. How much
> overlaps/duplicative groups did you end up having ?
>

Fair point, it wasn't many. The reason I recalled this effort was because
we had to go through the exercise after the fact and that made the volume
of WGs to review much larger than had we asked the purpose whenever they
were created. As long as we check back periodically and not let the work
for validation/clean up pile up then this is probably a non-issue.

>
> > Also, do we have to replace WGs as a concept or could SIG
> > augment them? One suggestion I have would be to keep projects on the TC
> > side and WGs on the UC side and then allow for spin-up/spin-down of SIGs
> > as needed for accomplishing specific goals/tasks (picture of a  diagram
> > I created at the Forum[1]).
>
> I feel like most groups should be inclusive of all community, so I'd
> rather see the SIGs being the default, and ops-specific or dev-specific
> groups the exception. To come back to my Public Cloud WG example, you
> need to have devs and ops in the same group in the first place before
> you would spin-up a "address scalability" SIG. Why not just have a
> Public Cloud SIG in the first place?
>

+1, I interpreted originally that each use-case would be a SIG versus the
SIG being able to be segment oriented (in which multiple use-cases could be
pursued)

>
> > [...]
> > Finally, how will this change impact the ATC/AUC status of the SIG
> > members for voting rights in the TC/UC elections?
>
> There are various options. Currently you give UC WG leads the AUC
> status. We could give any SIG lead both statuses. Or only give the AUC
> status to a subset of SIGs that the UC deems appropriate. It's really an
> implementation detail imho. (Also I would expect any SIG lead to already
> be both AUC and ATC somehow anyway, so that may be a non-issue).
>

We can discuss this later because it really is an implementation detail.
Thanks for the answers.

>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] Turning TC/UC workgroups into OpenStack SIGs

[Shamail Tahir]

Hi,

In the past, governance has helped (on the UC WG side) to reduce
overlaps/duplication in WGs chartered for similar objectives. I would like
to understand how we will handle this (if at all) with the new SIG proposa?
Also, do we have to replace WGs as a concept or could SIG augment them? One
suggestion I have would be to keep projects on the TC side and WGs on the
UC side and then allow for spin-up/spin-down of SIGs as needed for
accomplishing specific goals/tasks (picture of a  diagram I created at the
Forum[1]).

The WGs could focus on defining key objectives for users of a shared group
(market vertical like Enterprise or Scientific WG, horizontal function like
PWG) and then SIGs could be created based on this list to accomplish the
objective and spin-down. Similarly a project team could determine a need to
gather additional data/requirements or need help with a certain task could
also spin-up a SIG to accomplish it (e.g. updating an outdated docs set,
discussion on a specific spec that needs to be more thoroughly crafted,
etc.)

Finally, how will this change impact the ATC/AUC status of the SIG members
for voting rights in the TC/UC elections?

[1] https://drive.google.com/file/d/0B_yCSDGnhIbzS3V1b1lpZGpIaHBmc29S
aUdiYzJtX21BWkl3/

Thanks,
Shamail


On Wed, Jun 21, 2017 at 11:26 AM, Thierry Carrez <thie...@openstack.org>
wrote:

> Matt Riedemann wrote:
> > How does the re-branding or re-categorization of these groups solve the
> > actual feedback problem? If the problem is getting different people from
> > different groups together, how does this solve that? For example, how do
> > we get upstream developers aware of operator issues or product managers
> > communicating their needs and feature priorities to the upstream
> > developers?
>
> My hope is that specific developers interested in a given use case or a
> given problem space would join the corresponding SIG and discuss with
> operators in the same SIG. As an example, imagine an upstream developer
> from CERN, able to join the Scientific SIG to discuss with operators and
> users with Scientific/Academic needs of the feature gap, and group with
> other like-minded developers to get that feature gap collectively
> addressed.
>
> > No one can join all work groups or SIGs and be aware of all
> > things at the same time, and actually have time to do anything else.
> > Is the number of various work groups/SIGs a problem?
>
> I would not expect everyone to join every SIG. I would actually expect
> most people to join 0 or 1 SIG.
>
> > Maybe what I'd need is an example of an existing problem case and how
> > the new SIG model would fix that - concrete examples would be really
> > appreciated when communicating suggested governance changes.
> >
> > For example, is there some feature/requirement/issue that one group has
> > wanted implemented/fixed for a long time but another group isn't aware
> > of it? How would SIGs fix that in a way that work groups haven't?
>
> Two examples:
>
> - the "API WG" was started by people on the UC side, listed as a UC
> workgroup, and wasn't making much progress as it was missing devs. Now
> it's been reborn as a TC workgroup, led by a couple of devs, and is
> lacking app user input. Artificial barriers discourage people to join.
> Let's just call all of them SIGs.
>
> - the "Public Cloud WG" tries to cover an extremely important use case
> for all of OpenStack (we all need successful OpenStack public clouds).
> However, so far I've hardly seen a developer joining, because it's seen
> as an Ops group just trying to make requirements emerge. I want the few
> developers that OVH or CityCloud or other public clouds are ready to
> throw upstream to use the rebranded "Public Cloud SIG" as a rally point,
> to coordinate their actions. Because if they try to affect upstream
> separately, they won't go far, and we badly need them involved.
>
> Yes, it's mostly a rebranding exercise, but perception matters.
> Hope this clarifies,
>
> --
> Thierry Carrez (ttx)
>
> __________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [Forum] Moderators needed!

[Shamail Tahir]

Hi everyone,

Most of the proposed/accepted Forum sessions currently have moderators but
there are six sessions that do not have a confirmed moderator yet. Please
look at the list below and let us know if you would be willing to help
moderate any of these sessions.

The topics look really interesting but it will be difficult to keep the
sessions on the schedule if there is not an assigned moderator. We look
forward to seeing you at the Summit/Forum in Boston soon!

Achieving Resiliency at Scales of 1000+

Feedback from users for I18n & translation - important part?

Neutron Pain Points

Making Neutron easy for people who want basic networking

High Availability in OpenStack

Cloud-Native Design/Refactoring across OpenStack



Thanks,
Doug, Emilien, Melvin, Mike, Shamail & Tom
Forum Scheduling Committee
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Shamail Tahir]

Thanks Clint!

On Mon, Feb 27, 2017 at 2:41 AM, Clint Byrum <cl...@fewbar.com> wrote:

> Excerpts from Shamail Tahir's message of 2017-02-27 00:44:44 -0500:
> > Hi Clint,
> >
> > On Mon, Feb 27, 2017 at 12:25 AM, Clint Byrum <cl...@fewbar.com> wrote:
> >
> > > Excerpts from Matt Riedemann's message of 2017-02-26 19:48:50 -0600:
> > > > On 2/26/2017 6:52 PM, Clint Byrum wrote:
> > > > > During some productive discussions in the Stewardship Working
> Group PTG
> > > > > room, the subject of the mailing list came up. The usual questions
> > > > > around whether or not we should have per-project lists came up and
> the
> > > > > reasons we don't were re-affirmed. To recap those reasons:
> > > > >
> > > > >   * Cross posting is the pits
> > > > >   * People don't always know at the beginning of a thread that a
> > > > > discussion will need to go wider, leading to silos and
> confusion.
> > > > >
> > > > > So we turned to ways to help reduce peoples' load while reading
> e-mail,
> > > > > since many (most?) tend to opt out of reading openstack-dev.
> > > > >
> > > > > There are a number of ways that we can help, including teaching
> people
> > > > > to have more efficient workflows and use specific mail reading
> tools
> > > > > (don't worry, we're not adding an NNTP gateway.. yet). But one that
> > > > > received positive feedback from the room was to have moderated
> > > > > business-only mailing lists for each project.
> > > > >
> > > > > Basically, there are things that we _do_ know will not go wider
> when
> > > > > the thread begins. Just running through the threads on the February
> > > > > thread index, there are a few obvious classes:
> > > > >
> > > > >   * Mascots
> > > > >   * Social meetups
> > > > >   * Meeting logistics
> > > > >   * Core team membership
> > > > >
> > >
> > I'm curious as to how much of the traffic (such as the examples given)
> > generates message fatigue on new users but I do appreciate that we are
> > trying to find solutions to make it easier to enter into the mailing
> lists
> > around OpenStack without having to resort to digests.
> >
>
> I think it's worth analyzing it, if somebody has time. I do not. My wild
> ass guess is between 1 and 5 percent of all messages, but probably more
> like 5-10 percent of threads, as a lot of them are the shorter, less
> interesting threads.
>
> These seem like small numbers, but cognitive load is not linear and the
> number of threads people end up reading varies whether or not they use
> tags.
>
+1


>
> > > > There are likely others. The idea is that these messages would go
> into a
> > > > > ${project}-busin...@lists.openstack.org. Said list would be
> moderated
> > > by
> > > > > a team of the PTL's choosing, and we would admonish moderators to
> > > reject
> > > > > soundly any threads not obviously single project business related.
> > >
> > In this approach, we could send messages that fall within the ${
> > project}-busin...@lists.openstack.org to the dev ML as well.  This would
> > allow people who want only the ${project}-business news to get the
> content
> > without having to get all messages from the dev ML but at the same time
> > allow threads to be available to both subscribers (dev and
> > ${project}-business}.
> >
> > I hope we still advocate for subscribing to the openstack-dev mailing
> list
> > even if a contributor is only starting with a single project (and not
> > interested in cross-project things) because it allows for people to see
> > conversations they might have expertise in or find a new project they
> want
> > to contribute to based on learning something new about it.
> >
>
> Wow, I must have failed in my wording ,sorry about that, because you
> got it 100% backwards. The idea is that everyone stays in openstack-dev
> for _all_ discussions (single-project as well). Only the most mundane
> but necessary emails go on per-project "business lists". So there would
> be zero point in ever subscribing to the business lists without also
> subscribing to openstack-dev, and likewise, republishing business lists
> to openstack-dev would defeat the entire point.
>

Makes sense!  Sorry if I missed the intent.  In this case, I am in
agreement with the original approach as well... my (unfounded) concern was
about what it would do to openstack-dev traffic.

>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][swg] per-project "Business only" moderated mailing lists

[Shamail Tahir]

t mail workflow with offlineimap and
> "sup" that lets me read the whole mailing list and aggressively filter
> threads without losing my mind and while still retaining useful search
> ability. I do not use folders other than putting anything with a List-Id
> into "lists". I published a little bit of it here btw:
>
> https://github.com/SpamapS/ferk (Firehose Email Reading Kit)
>
> But I never finished publishing docs or useful templates for sup config.
>
> And really, I don't expect every new participant in OpenStack to adopt
> such a workflow. It's taken me at least 6 years to get it dialed in and
> it's tuned to not only OpenStack but Debian and other smaller projects.
>
> You have taken the folder approach, and that is a bit less complicated
> to set up than sup+offlineimap, but still does require that you know
> how to filter by tag. It also means that you are experiencing one of
> the problems with cross posting whenever anybody adds a tag, as in
> that setup each message is duplicated into each folder, or you have a
> 'first match' sieve and then tag order becomes significant. Either way,
> you have to flip back and forth to read a thread. Or maybe somebody has
> an answer? Nobody in the room at the SWG session had one.
>
> Anyway, that's fine tuning for old-hats at managing openstack-dev. We
> are still throwing hundreds of messages per week at anyone who dares to
> try and be cross-project. For those involved with a few projects, it's
> relatively simple to pick a few business lists to keep up with _once
> you have reached that level of involvement_. Until then, what you want
> on openstack-dev is development discussions.
>
> Nobody is saying you can't announce things about each project on
> the list. But there's obvious stuff that is just logistics about an
> established project team's business, and a complete waste of time to
> even have to filter by thread. We've gotten _really_ wide over the
> years. So if you have a better strategy to help newbies deal with that
> and not get funneled into a silo _immediately_, do share. But for now,
> this is an attempt to relieve the overall system of at least a small
> amount of pressure.
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [ux] Future of the OpenStack UX team

[Shamail Tahir]

On Wed, Jan 4, 2017 at 9:43 AM, Thierry Carrez <thie...@openstack.org>
wrote:

> Hi everyone,
>
> Piet recently reached out to me to explain that he won't be able to
> continue in his role as OpenStack UX team's PTL. Since he created the
> team and spent a lot of time coordinating its activities, that raises
> the question of the future of the OpenStack UX team.
>
> The situation was discussed at the TC meeting yesterday[1] and the
> general feeling was that there was a lot of value in a separate team
> centralizing things like Persona definition and facilitating
> properly-conducted UX surveys. That said, if nobody is able to dedicate
> the time that effort needs, we could also disband the centralized team
> and encourage every project to adopt the tools and techniques that were
> built and introduced by the UX team in the past years.
>
> So... What are your thoughts on those options ? Do we have a volunteer
> (or more than one) to take over UX PTLship ?
>
Hi Thierry,

I had set up a doodle poll to gauge interest/establish a new meeting time
for the UX working group but we only had one additional response.  How
should we proceed since it seems there was low interest in participation?

>
> [1]
> http://eavesdrop.openstack.org/meetings/tc/2017/tc.2017-
> 01-03-20.00.log.html#l-404
>
> --
> Thierry Carrez (ttx)
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [ux] Poll for next team meeting

[Shamail Tahir]

Hi everyone,

Per the discussion on the dev mailing list last week[1], I am sending out a
poll to determine when the UX working group should meet. Please indicate
your time preference(s) in the poll if you are interested in participating
in the OpenStack UX efforts.  Agenda will be sent out after we determine a
time.  I will be closing the poll on Feb. 9th, 2017 @ 23:59 UTC.

Poll: http://doodle.com/poll/76bnere6ztdg7hgd

-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time

[1]
http://lists.openstack.org/pipermail/openstack-dev/2017-January/109622.html
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][tc] establishing project-wide goals

[Shamail Tahir]

On Mon, Aug 1, 2016 at 7:58 AM, Doug Hellmann <d...@doughellmann.com> wrote:

> Excerpts from Sean Dague's message of 2016-08-01 08:33:06 -0400:
> > On 07/29/2016 04:55 PM, Doug Hellmann wrote:
> > > One of the outcomes of the discussion at the leadership training
> > > session earlier this year was the idea that the TC should set some
> > > community-wide goals for accomplishing specific technical tasks to
> > > get the projects synced up and moving in the same direction.
> > >
> > > After several drafts via etherpad and input from other TC and SWG
> > > members, I've prepared the change for the governance repo [1] and
> > > am ready to open this discussion up to the broader community. Please
> > > read through the patch carefully, especially the "goals/index.rst"
> > > document which tries to lay out the expectations for what makes a
> > > good goal for this purpose and for how teams are meant to approach
> > > working on these goals.
> > >
> > > I've also prepared two patches proposing specific goals for Ocata
> > > [2][3].  I've tried to keep these suggested goals for the first
> > > iteration limited to "finish what we've started" type items, so
> > > they are small and straightforward enough to be able to be completed.
> > > That will let us experiment with the process of managing goals this
> > > time around, and set us up for discussions that may need to happen
> > > at the Ocata summit about implementation.
> > >
> > > For future cycles, we can iterate on making the goals "harder", and
> > > collecting suggestions for goals from the community during the forum
> > > discussions that will happen at summits starting in Boston.
> > >
> > > Doug
> > >
> > > [1] https://review.openstack.org/349068 describe a process for
> managing community-wide goals
> > > [2] https://review.openstack.org/349069 add ocata goal "support
> python 3.5"
> > > [3] https://review.openstack.org/349070 add ocata goal "switch to
> oslo libraries"
> >
> > I like the direction this is headed. And I think for the test items, it
> > works pretty well.
> >
> > I'm trying to think about how we'd use a model like this to support
> > something a little more abstract such as making upgrades easier. Where
> > we've got a few things that we know get in the way (policy in files,
> > rootwrap rules, paste ini changes), as well as validation, as well as
> > configuration changes. And what it looks like for persistently important
> > items which are going to take more than a cycle to get through.
>
> If we think the goal can be completed in a single cycle, then those
> specific items can just be used to define "done" ("all policy
> definitions have defaults in code and the service works without a policy
> configuration file" or whatever). If the goal cannot be completed in a
> single cycle, then it would need to be broken up in to phases.
>
> >
> > Definitely seems worth giving it a shot on the current set of items, and
> > see how it fleshes out.
> >
> > My only concern at this point is it seems like we're building nested
> > data structures that people are going to want to parse into some kind of
> > visualization in RST, which is a sub optimal parsing format. If we know
> > that people want to parse this in advance, yamling it up might be in
> > order. Because this mostly looks like it would reduce to one of those
> > green/yellow/red checker boards by project and task.
>
> That's a good idea. How about if I commit to translate what we end
> up with to YAML during Ocata, but we evolve the first version using
> the RST since that's simpler to review for now?

We have created a tracker file[1][2] for user stories (minor changes
pending based on feedback) in the Product WG repo.  We are currently
working with the infra team to get a visualization tool deployed that shows
the status for each artifact and provides links so that people can get more
details as necessary.  Could something similar be (re)used here?

I also have a general question about whether goals could be documented as
user stories[3]?


>


> Doug
>
> >
> > -Sean
> >
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time

[1]
https://github.com/openstack/openstack-user-stories/blob/master/doc/source/tracker_overview.rst
[2]
https://github.com/openstack/openstack-user-stories/blob/master/user-story-tracker.json
[3]
https://github.com/openstack/openstack-user-stories/blob/master/user-story-template.rst
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Timeframe for naming the P release?

[Shamail Tahir]

On Mon, May 2, 2016 at 2:58 PM, Monty Taylor <mord...@inaugust.com> wrote:

> On 05/02/2016 01:53 PM, Shamail Tahir wrote:
>
>> Hi everyone,
>>
>> When will we name the P release of OpenStack?  We named two releases
>> simultaneously (Newton and Ocata) during the Mitaka release cycle.  This
>> gave us the names for the N (Mitaka), N+1 (Newton), and N+2 (Ocata)
>> releases.
>>
>> If we were to vote for the name of the P release soon (since the
>> location is now known) we would be able to have names associated with
>> the current release cycle (Newton), N+1 (Ocata), and N+2 (P).  This
>> would also allow us to get back to only voting for one name per release
>> cycle but consistently have names for N, N+1, and N+2.
>>
>
> Patches already up ...
>
> https://review.openstack.org/#/c/310425/
>
> https://review.openstack.org/#/c/310426/


Thanks Monty.  Shouldn't we just starting naming one release again?  This
will give the community the names of the next three releases
consistently... If we would for two of them at a time then we will have
some periods where four names will be known and others where we might only
know three (i.e. during Ocata).


>
> Monty
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] Timeframe for naming the P release?

[Shamail Tahir]

Hi everyone,

When will we name the P release of OpenStack?  We named two releases
simultaneously (Newton and Ocata) during the Mitaka release cycle.  This
gave us the names for the N (Mitaka), N+1 (Newton), and N+2 (Ocata)
releases.

If we were to vote for the name of the P release soon (since the location
is now known) we would be able to have names associated with the current
release cycle (Newton), N+1 (Ocata), and N+2 (P).  This would also allow us
to get back to only voting for one name per release cycle but consistently
have names for N, N+1, and N+2.

-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] Summit Core Party after Austin

[Shamail Tahir]

On Thu, Apr 21, 2016 at 2:43 PM, Tim Bell <tim.b...@cern.ch> wrote:

>
> On 21/04/16 19:40, "Doug Hellmann" <d...@doughellmann.com> wrote:
>
> >Excerpts from Thierry Carrez's message of 2016-04-21 18:22:53 +0200:
> >> Michael Krotscheck wrote:
> >>
> >>
> >> So.. while I understand the need for calmer parties during the week, I
> >> think the general trends is to have less parties and more small group
> >> dinners. I would be fine with HPE sponsoring more project team dinners
> >> instead :)
> >
> >That fits my vision of the new event, which is less focused on big
> >glitzy events and more on small socializing opportunities.
>
> At OSCON, I remember some very useful discussions where tables had signs
> showing
> the topics for socializing. While I have appreciated the core reviewers
> (and others)
> events, I think there are better formats given the massive expansion of
> the projects
> and ecosystem, which reduce the chances for informal discussions.
>
+1

This is a great idea.. The topics could even be sourced similar to how
lightning talks are determined.  If there is a topic that you are
interested then post/write it down and others can +1 it.

>
> I remember in the OpenStack Boston summit when there was a table marked
> ‘Puppet’ which was one of the most
> productive discussions I have had in the OpenStack summits (Thanks Dan :-)
>
> Tim
>
> >
> >Doug
> >
> >__
> >OpenStack Development Mailing List (not for usage questions)
> >Unsubscribe:
> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> >http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [election][tc] TC Candidacy for Shamail Tahir

[Shamail Tahir]

Hi everyone,

I would like to announce my candidacy for OpenStack Technical Committee
member for the upcoming term.

I am currently an offering manager for OpenStack initiatives at IBM and I
have been involved in the OpenStack community since 2013.  I spend most of
my time[1] in our working groups including the Product, Enterprise,
Application Ecosystem, and Operator Tags team..  I have also spent a lot of
time talking with OpenStack users and organizations that are new to
open-source and OpenStack in order to help them with their journey into
becoming community members.  The OpenStack project continues to gain
adoption while also expanding in scope with new projects and
functionality.  These changes continue to make considering operator and
user experience in strategic and architectural decisions ever more
critical.  Furthermore, the TC itself is involved in a set of broad topics
lately (such as changing the mission statement, diversity, and mentoring to
name a few) and additional perspectives will be good for these discussions.

If elected to be a TC, I would like to focus/highlight on the topics
outlined below:

   * Revisit big-tent workflow for new projects.

- The big tent initiative has promoted faster and broader
innovation inside the OpenStack community and I believe we should reflect
on its first year to build a new set of best practices for both acceptance
and on-boarding new projects along with mechanisms to validate that new
projects are continuing to follow the four opens.  What worked? What
didn't?  Should there be additional criteria based on overall fit/need? And
how can we improve this further?



  * Promote a systems architecture point-of-view of the OpenStack cloud
platform

- There are several initiatives under-way (with more to come) that
can benefit multiple OpenStack projects.  Cross project specifications
allow us to build best practices and guidelines but they are currently
treated as recommendations.  If we could develop a way to make some of the
more critical needs a requirement vs. recommendation then we could have a
way to ensure that we have a way inside the community to drive
architectural changes, as necessary, for better system stability, user
experience, or performance.  The other benefit would be to agree on common
needs (e.g. the quota service discussion happening right now, the online
schema migration work that has taken place in a lot of projects) and guide
new projects through adopting the changes as they start development rather
than retrofit.

   * Increase user and technical committee exchanges

   - I would like to propose a regular cadence to discussions between
the technical and user committee members so that technical direction, and
decision points, can be shared and we could strengthen/expedite feedback
from our user community into process as needed.  I have seen both parties
appreciate the dialogue and find it valuable, therefore I think anything
that can strengthen this feedback loop is a positive thing.

   * Building an ecosystem for next-generation platforms

   - Over the last couple of years there have been multiple
complementary open-source projects/technologies that are catering to
similar application design patterns (Mesos, k8s, Cloud Foundry, etc,).  I
believe projects such as Kuryr are doing a good job in mapping OpenStack
technologies like neutron to other ecosystems (e.g Docker libnetwork) and
we should continue to solicit more projects/activity that will help
customers/users build an internal platform that meets their objectives as
they shift from traditional applications to newer applications.  In the
end, we are all trying to meet user needs and the answer probably lies in a
complementary view of adjacent technologies versus every need being
implemented by a single platform.  A successful approach to building an
ecosystem for OpenStack clouds could dramatically increase putting our code
to work through an even greater adoption rate and make OpenStack clouds
viable for additional workloads/use-cases.

My reason for focusing on these topics is based on my experience and
background in the OpenStack community.  I am a core member of the Product
working group[2], participate regularly in the ops-tags-team[3], help with
SuperuserTV[4], help with building the community-generated OpenStack
roadmap[5], and moderate sessions at ops-meetups.

I am passionate about the work our community produces and excited that it
has found relevance for so many people and organizations around the globe.
I would like to continue to do work that further strengthens the feedback
loop between the developers and consumers of our open-source cloud.  I
humbly ask for your vote to represent this need as a member of our
OpenStack Technical Committee.


[1] https://review.openstack.org/#/q/owner:ItzShamail%2540gmail.com

[2] https://wiki.openstack.org/wiki/ProductTeam

[3] https://review.openstack.org/#/q/project:openstack/ops-tags-team

[4] 

[openstack-dev] Encouraging first-time contributors through bug tags/reviews

[Shamail Tahir]

Hi everyone,

Andrew Mitry recently shared a medium post[1] by Kent C. Dobbs which
discusses how one open-source project is encouraging contributions by new
open-source contributors through a combination of a special tag (which is
associated with work that is needed but can only be completed by someone
who is a first-time contributor) and helpful comments in the review phase
to ensure the contribution(s) eventually get merged.

While reading the article, I immediately thought about our
low-hanging-fruit bug tag which is used for a very similar purpose in "bug
fixing" section of  the "how to contribute" page[2].  The low-hanging-fruit
tag is used to identify items that are generally suitable for first-time or
beginner contributors but, in reality, anyone can pick them up.

I wanted to propose a new tag (or even changing the, existing, low-hanging
fruit tag) that would identify items that we are reserving for first-time
OpenStack contributors (e.g. a patch-set for the item submitted by someone
who is not a first time contributor would be rejected)... The same article
that Andrew shared mentions using an "up-for-grabs" tag which also
populates the items at up-for-grabs[3] (a site where people looking to
start working on open-source projects see entry-level items from multiple
projects).  If we move forward with an exclusive tag for first-timers then
it would be nice if we could use the up-for-grabs tag so that OpenStack
also shows up on the list too.  Please let me know if this change should be
proposed elsewhere, the tags are maintained in launchpad and the wiki I
found related to bug tags[4] didn't indicate a procedure for submitting a
change proposal.

Tyler Britten also suggested maybe even having a pool of reviewers who
could monitor items being worked on that fall in this "first-timer"
category who could further help the new contributors by helpful review
comments and answering questions if the contributors get stuck on some part
of the process.  Could this be the same people who helped make the upstream
training[5] successful?  I look forward to thoughts on this matter.

[1] https://medium.com/@kentcdodds/first-timers-only-78281ea47455#.707dal290
[2] https://wiki.openstack.org/wiki/How_To_Contribute#Bug_fixing
<https://wiki.openstack.org/wiki/How_To_Contribute#Bug_fixing>
[3] http://up-for-grabs.net/
[4] https://wiki.openstack.org/wiki/Bug_Tags
[5] http://docs.openstack.org/upstream-training/


-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [tc] projects.yaml (project since data)

[Shamail Tahir]

Hi,

In the older integrated release model we used to have a field that showed
"integrated-since" data about a project.  I was just reviewing the current
projects.yaml[1] file and noticed that there is no information in there
that shows how long a project has been under OpenStack governance.  That
data was useful to plot growth of overall project count, # of release
cycles a project has been under OpenStack governance, etc.  I realize there
are other ways of getting this information but this was a very easy place
to get this data for all projects at once...

Would it be feasible to add an "official-since" into projects.yaml?  The
value could tie to when the TC approves a project (since not all projects
have to adhere with the 6-month release itself).


[1]
https://git.openstack.org/cgit/openstack/governance/tree/reference/projects.yaml
-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] service catalog: TNG

[Shamail Tahir]

uses toke
> bloat, and has led to other features to try to shrink the catalog by
> filtering it by what a user is allowed. Which in turn ended up being
> used by Horizon to populate the feature matrix users see.
>
> ++

> So we're pulling on a thread, and we have to do that really carefully.
>
> I think the important thing is to focus on what we have in 6 months
> doesn't break current users / applications, and is incrementally closer
> to our end game. That's the lens I'm going to keep putting on this one.
>
Agreed, but knowing future preferences is not a bad thing either (as long
as focus doesn't get diluted on the next 6 months)

Finally, as mentioned by Clint, consul does provide DNS-SD (but not
DNS-TXT) interface so using it as a backend allows us to focus on REST but
set ground work for DNS too.

>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all] [ptl] Troubleshooting cross-project communications

[Shamail Tahir]

imilar to how the Product WG structure is setup as well.  We
have cross-project liaisons (CPLs) that participate in the project team
meetings and also user-story owners who cover the overall goal of
completing the user story.  The user story owner leverages the cross
project liaisons to help with tracking component/project specific
dependencies for implementing the user story but the user story owner is
looking at the overall state of the bigger picture.   Our CPLs work with
multiple user-story owners but the user story owner to user story mapping
is 1:1.

>
>>
> Or, to dig into this further, continue along the lines of the TC specialty
> teams we've set up? We ran out of time a few TC meetings ago to dive into
> solutions here, so I'm glad we can continue the conversation.
>
> I'm sure existing cross-project teams have ideas too, liaisons and the
> like may be matrixed somehow? We'll still need accountability and matching
> skill sets for tasks.
>

> Anne
>
>
>> Maybe cross-project initiatives are too important to be left to the
>> energy of an individual and rely on random weekly meetings to make
>> progress. They might need a clear team to own them.
>>
>> --
>> Thierry Carrez (ttx)
>>
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe:
>> openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
> --
> Anne Gentle
> Rackspace
> Principal Engineer
> www.justwriteclick.com
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>


-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][TC] 'team:danger-not-diverse tag' and my concerns

[Shamail Tahir]

On Fri, Sep 11, 2015 at 3:26 PM, Joshua Harlow <harlo...@outlook.com> wrote:

> Hi all,
>
> I was reading over the TC IRC logs for this week (my weekly reading) and I
> just wanted to let my thoughts and comments be known on:
>
>
> http://eavesdrop.openstack.org/meetings/tc/2015/tc.2015-09-08-20.01.log.html#l-309
>
> I feel it's very important to send a positive note for new/upcoming
> projects and libraries... (and for everyone to remember that most projects
> do start off with a small set of backers). So I just wanted to try to
> ensure that we send a positive note with any tag like this that gets
> created and applied and that we all (especially the TC) really really
> considers the negative connotations of applying that tag to a project (it
> may effectively ~kill~ that project).
>
> I would really appreciate that instead of just applying this tag (or other
> similarly named tag to projects) that instead the TC try to actually help
> out projects with those potential tags in the first place (say perhaps by
> actively listing projects that may need more contributors from a variety of
> companies on the openstack blog under say a 'HELP WANTED' page or
> something). I'd much rather have that vs. any said tags, because the latter
> actually tries to help projects, vs just stamping them with a 'you are bad,
> figure out how to fix yourself, because you are not diverse' tag.
>
> I believe it is the TC job (in part) to help make the community better,
> and not via tags like this that IMHO actually make it worse; I really hope
> that folks on the TC can look back at their own projects they may have
> created and ask how would their own project have turned out if they were
> stamped with a similar tag...
>

I agree with Josh and, furthermore, maybe a similar "warning" could be
implicitly made by helping the community understand why the
"diverse-affiliation" tag matters.  If we (through education on tags in
general) stated that the reason diverse-affiliation matters, amongst other
things, is because it shows that the project can potentially survive a
single contributor changing their involvement then wouldn't that achieve
the same purpose of showing stability/mindshare/collaboration for projects
with diverse-affiliation tag (versus those that don't have it) and make
them more "preferred" in a sense?

Thanks,
Shamail


> - Josh
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Thanks,
Shamail Tahir
t: @ShamailXD
tz: Eastern Time
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev