Current Bi Weekly Live Hangout

25 views
Skip to first unread message

Ken Finnigan

unread,
Aug 21, 2018, 3:19:25 PM8/21/18
to Eclipse MicroProfile
All,

Though I've been wondering it for a while, today's meeting cemented my view that something needs to change with respect to the Live Hangouts.

There are a couple of issues I see occurring on a regular basis:
  • Simply not enough time in one hr to go through all the topics.
  • Agenda items being added last minute into higher position. This was particularly apparent today as two items I'd added were #'s 3 and 4 prior to the meeting, but kept being bumped down until they weren't able to be discussed except one brief mention.
To try and resolve these it might be necessary to consider adding either a regular, or ad-hoc, call in the off weeks to cover topics that weren't able to be discussed in the original meeting they were added to. This is beneficial for topics that are time critical and can't necessarily wait another two weeks before they can be discussed, or where the person raising a topic is not available at the next call and would then need to wait four weeks to present their topic.

Another option is being stricter around Agenda items and defining the priority of discussions before the meeting starts, to prevent items from "jumping the queue" without reasonable justification.

Thoughts?

Ken

James Roper

unread,
Aug 21, 2018, 5:44:56 PM8/21/18
to MicroProfile
Hi Ken,

The points you raise are all good, but we also talked about adding even more to the agenda, specifically setting aside the first 20 minutes or so for demos, so there's some competing concerns here.

What if we made every other week, at the same time slot, for demos? So the regular meetings happen as usual, and demos happen in the other weeks. Demos can take up a lot of time and can trigger other discussions that are typically not important enough to warrant pushing other items off the agenda. This way, we can give demos a decent chance with a reasonable amount of time for questions. If we decide to go ahead with that, then perhaps we could make the Reactive Streams Ops demo the first such hangout, in 3 weeks time.

The downside of this idea is that it lowers the priority/importance of demos, since they won't be part of the "main" meeting, and so we would expect a smaller audience for them (if the audience isn't smaller, then all we'll have achieved is added an extra meeting, which many people don't want). I'm not sure how people will feel about that - personally, I'm not interested in every demo and am happy to just look at docs for demos that I'm not interested in, so for me it would work, but some people might feel that they are interested in every demo so this would be adding to their meeting workload.

Of course, this doesn't replace any of your other suggestions, it's just an additional suggestion to help manage the time.

Cheers,

James

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a91d860b-5c66-44d5-bd20-b4535ac69b3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
James Roper
Senior Developer, Office of the CTO

Lightbend – Build reactive apps!
Twitter: @jroper

Ken Finnigan

unread,
Aug 22, 2018, 9:08:53 AM8/22/18
to MicroProfile
Hi James,

Yes, I appreciate we're trying to cram ever more into a single hour of everyones time.

Your idea around demos being in the "off weeks" is possible, but then it does have the problem you describe of not everyone showing up. If it's able to be recorded that's less of a problem, but right now we've got issues with that as well.

To tackle the amount that needs to be demo'd, discussed, etc, there's two obvious options:
  • Be extremely strict about what's on the agenda and how long each is discussed. This would prevent items being bumped in front of others during the meeting, etc, while ensuring each item that was on the agenda has enough time to be discussed. The downside is that it means there are things that can't make it onto the agenda for a given meeting.
  • Make the current bi weekly meeting a weekly one. I know we've all said there are too many meetings already, but it's not always practical for an item to wait another 2 weeks to be discussed. Things can change very quickly in the span of two weeks.
In an effort to reduce what's being discussed in the meetings, maybe we need to take a different approach to release planning?

Currently it's very much a "pull" model where the umbrella spec is pulling information from the sub specs about their release plans and what they will have available, etc. Would it be worthwhile switching to a "push" model, where release information is pushed from the sub specs up?

I know not all sub spec leads are able to make the bi weekly call, so often they're not able to answer questions about when a release is going to be ready. The sub specs could maintain some form of roadmap with simple release timelines that could be used by the larger group to determine what sub specs can be included? If the umbrella spec sets a cut off date a few months in advance, then sub specs are better able to plan their work to that date and if they miss the date there will be another release in a quarter.

Related to that I think we need to move away from the mentality of "not enough in the umbrella release". We chose a time boxed release cadence to have a defined schedule. That decision does also mean that there might be times where there are no sub spec releases for inclusion in a larger umbrella release and we decide not to do an MP wide release. I don't see anything wrong with that. There will be times when more is happening than at others, especially if there's lots of people on holidays at certain times of the year.

Anyway, I think I've derailed myself enough for this one thread.

Ken

John Clingan

unread,
Aug 23, 2018, 3:40:27 AM8/23/18
to Eclipse MicroProfile
Ken, thanks for the writeup. As the person that tends to run these meetings, I have to make judgement calls since we don't really have enough time to cover all topics. For example, I also *really* wanted to get to the MP demo post you made but didn't have time. I've always wanted this to be primarily a status call, but it really is more than that. To be honest, I start the call 5 minutes after the hour so we can hit critical mass. I may stop that.

So, we can add more formality to the call:
  1. Start on time. Anyone who joins late will have to watch the recording or read the meeting minutes to catch up. Start recording at 1 minute after the hour, period.
  2. Put time limits on discussions (ahead of time). Status updates should be brief, with most inter-spec discussions having been hashed out ahead of time or "take it offline". I have no problem being "that person" who is strict at keeping the discussion very on-point.
  3. Be more strict about ensuring every spec team has representation on the call, or update status before meeting. Again, I can be "that person". A status update can be as simple as "no update" or "need to coordinate with another spec on <a topic>".
  4. To be frank, I don't want this meeting to be "first come first serve" in terms of discussion topics. There needs to be a way to prioritize. Right now I make judgement calls. Perhaps that's too loosy-goosy, so I'm open to suggestions.
  5. Demos and new spec introductions are scheduled separately (and recorded).
The above should free up time for more topics, and anything not finished in a time slot can be addressed in the google group. This will encourage "to the point" discussion.. Otherwise, we turn it from a bi-weekly meeting to a weekly meeting. Even weeks there is a fixed format  - spec/release status, marketing update and anything else we come up with that meets a static format. Odd weeks - free-flow format (including demos), first come first serve. No-one likes more meetings, but there is simply too much to cover in a single hour.

Thoughts?
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a91d860b-5c66-44d5-bd20-b4535ac69b3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
James Roper
Senior Developer, Office of the CTO

Lightbend – Build reactive apps!
Twitter: @jroper

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.

Ken Finnigan

unread,
Aug 29, 2018, 4:32:06 PM8/29/18
to Eclipse MicroProfile


On Thursday, August 23, 2018 at 3:40:27 AM UTC-4, John Clingan wrote:
Ken, thanks for the writeup. As the person that tends to run these meetings, I have to make judgement calls since we don't really have enough time to cover all topics. For example, I also *really* wanted to get to the MP demo post you made but didn't have time. I've always wanted this to be primarily a status call, but it really is more than that. To be honest, I start the call 5 minutes after the hour so we can hit critical mass. I may stop that.

So, we can add more formality to the call:
  1. Start on time. Anyone who joins late will have to watch the recording or read the meeting minutes to catch up. Start recording at 1 minute after the hour, period.
Sounds good. 
  1. Put time limits on discussions (ahead of time). Status updates should be brief, with most inter-spec discussions having been hashed out ahead of time or "take it offline". I have no problem being "that person" who is strict at keeping the discussion very on-point.
Not always practical with items that are being added during the meeting, which I see as a big issue at present.
  1. Be more strict about ensuring every spec team has representation on the call, or update status before meeting. Again, I can be "that person". A status update can be as simple as "no update" or "need to coordinate with another spec on <a topic>".
I'm almost wondering whether there's any benefit to a "round table of status" anymore. Even with a set time for it, trying to cover a growing list of specs becomes difficult. I only see value in status when an MP umbrella release is being planned, and even then it might be worth moving to a "push" model where the sub specs are sending notifications to the wider group about which version they want to propose for the next MP release. Instead of the wider group trying to pull a release out from a sub spec. That may open the MP umbrella spec up to the problem of not much in a release, but that may be a risk we have to take without taking the path of dictating sub spec release cadence. We need to accept that we're giving the sub specs the freedom to set their cadence, which will sometimes mean that an MP time boxed release has only 1 or 2 updates.

From a marketing perspective I can appreciate that it makes it difficult to "sell" a release with only one or two updates, but that's counter balanced with more MP releases having 4, 5, or more updates in a single release. There are going to be ebbs and flows based on everyone's non MP work and normal life. Either we accept there may be misalignment between MP umbrella releases being time boxed and the sub specs having a release cadence of their own choosing, or we align the two.
  1. To be frank, I don't want this meeting to be "first come first serve" in terms of discussion topics. There needs to be a way to prioritize. Right now I make judgement calls. Perhaps that's too loosy-goosy, so I'm open to suggestions.
I don't really mind how it's prioritized, but right now I get the sense any one can pipe up with a topic and that will be discussed over something that was defined in the minutes before hand. 
  1. Demos and new spec introductions are scheduled separately (and recorded).
Sounds good
 
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a91d860b-5c66-44d5-bd20-b4535ac69b3d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


--
James Roper
Senior Developer, Office of the CTO

Lightbend – Build reactive apps!
Twitter: @jroper

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
Reply all
Reply to author
Forward
0 new messages