Better communication of impactful changes

[John D. Ament]

All

Just want to throw this out there, and see how others feel.

I know we're all experimenting with APIs and trying to come up with ways to make the technology work together.  There are going to be unavoidable cases where a change has to come in that potentially breaks others builds.  I would like to see more communication of these types of changes in the future, and figure out if there's a way to make sure everyone's aware and on board with the change.  I'm not sure if that means we communicate more on the google group list, send emails, etc, but we need to think about how to be better citizens in the ecosystem.

John

[Emily Jiang]

Hi John,

If it is related to one git repo, I think it is best to follow up with an issue. If the change has a big impact on multiple projects etc, sending an email will be good. Let me know if I misunderstand your questions.

my 2cents.

Emily

[Kevin Sutter]

I agree, John.  This has been one of my concerns with the Google Group...  It's just too easy to miss important information.  We have so many threads going, it's hard to keep up.  And, it's hard to determine the "big, important" changes.

Pinning particular messages has helped a bit.  But, we might run into having too many pinned conversations like we did a few months back...  We would have to be diligent on cleaning up these pinned messages.  Actually, long-living pinned messages should probably make it to our wiki instead of staying pinned.  The wiki could always reference back to the conversation for historical purposes.

We still have the micropro...@eclipse.org mailing list available to us.  All developers should be subscribed to this.  Maybe we could use this to communicate these type of important changes?

I also agree with your comment about being better citizens.  We all have to be aware that we're not developing in a vacuum.   Other teams are dependent on our component's artifacts and we should attempt to communicate any possible breaking changes to all affected parties.

Thanks, Kevin

[Ken Finnigan]

+1 to comments so far.

Ideally we don't want to be creating yet another location for where this important information needs to be raised.

Maybe we can have a prefix to the subject on Google Group thread of "[PROPOSED BREAKING CHANGE]" to make it more prominent in mail clients?

Ken

--
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.
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/6f98c943-e451-4421-b1a9-a507133c792e%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[David Blevins]

Also +1 on the general concept of flagging more important changes.

My suggestion here would be simple, start a new thread with “[CHANGE]” or “[PROPOSAL]” in the subject and and a clear title indicating where the change/proposal is.

We have a lot of discussion on threads where the subject is “Agenda Foo, Sept 1”.  Minutes are great and needed, all subjects look the same so they do not help in flagging up any important discussion.  In addition to minutes, we should start threads for any larger items.

-- 

David Blevins

http://twitter.com/dblevins
http://www.tomitribe.com

310-633-3852

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/CAKeeVe7-bJUsQv9WV7o9m50MrpHiXDXmpbyO58w2w0SiGWkEYQ%40mail.gmail.com.

[John D. Ament]

Emily,

The issue is more general, in that there are times when we push up changes to a spec when others may have already implemented it a different way.  When we push up changes to TCKs or APIs, we are not always aware that others may have it as a snapshot dependency, which can cause some build issues.  We just have to be cognizant that these dependencies do exist.

[Ondro Mihályi]

I agree that breaking API changes during snapshot development need to be done with care. However, there's no need to distribute the information via the mailing list.

I think, it should be enough to be explicit about it in the PR, adding a warning into the PR's title and description. Ideally waiting for others to comment before merging the PR. Implementors should follow notifications about new PRs, and even if they don't they can go through merged PRs to check if there were any important or breaking changes merged. Having a label to tag such PRs would be even better for filtering, but labels don't show in email notifications on the other hand.

--Ondro

[Ken Finnigan]

Maybe we also need to instigate some level of PR approvals before things are merged, to allow that time for feedback?

I know at present a lot of PRs on spec repositories are merged not long after being created, perhaps the above could help with that?

--

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.
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/6cc502a2-c532-4c03-85ae-0263b832ad03%40googlegroups.com.

[John D. Ament]

Ondro,

I think if we were using PR's differently what you're describing could work.  For it to happen, the person raising the PR needs to make people aware and wait for them to acknowledge the PR before merging it.  I don't think we always do that.

John

[Ondro Mihályi]

I think we should do that, really.

For small PRs, it's fine to merge them automatically. For PRs with a bigger impact, we should wait a couple of days to give space for reviewers. This is what I actually do when I feel my PR is suitable for a proper review.

Proposing big changes and merging them arbitrarily is very unfriendly. Even lack of time and hurry don't justify skipping the review process completely. However, it's up to the author to decide what's worth to review.

--Ondro

[Ken Finnigan]

I don't think it would be a bad idea to mandate at least one approval from someone other than the author of a PR before its merged.

It sets a good precedent and respects the input of the community, even for simple PRs.

--

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.
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/955098c4-b588-4cd0-b5a3-945374e577d8%40googlegroups.com.

[Kevin Sutter]

>  I don't think it would be a bad idea to mandate at least one approval from someone other than the author of a PR before its merged.

+1

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/a7R3muaWPzE/unsubscribe.
To unsubscribe from this group and all its topics, 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/CAKeeVe65%2B8Z34mCu1weZ31G_qpASRhde5HeGNYaPQzEX5msWyg%40mail.gmail.com.

[Alasdair Nottingham]

+1 I quite often want to comment on something and then it is too late because it got merged, so I don’t.

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/CABH8er%3DTQXL-y6qRfCoZ2BOqWjwTebEOWi83gDMms-aBgy%3DqjA%40mail.gmail.com.

[Mark Little]

Agreed.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/1F34EC20-3B83-405D-A83E-7E3F2EBFEB1E%40gmail.com.

[Heiko Braun]

In general I agree with pretty much everything said here so far, but we need to keep in mind that the subprojects cannot always wait for everyone to provide feedback. Our attention span is limited and we work with different schedules, timezones and external obligations.

I think the case John mentioned describes an implementor trying to keep track with changes in his/her implementation. Maybe this situation can be dealt with otherwise? I.e. compatibility guidelines for releases (breaking changes disallowed between minors) and "official" review phases for RC's that allow implementors to update and adjust? 

I think it would be useful relief the day to day activities of a subproject from these concerns and move to more coarse grained "review" cycles, that everybody can plan for ahead of time. 

Does that make sense?

[Kevin Sutter]

Heiko,

I agree that we can't slow every component down just so that us laggers can keep up...  :-)  But, I think requiring at least one review approval before merging code is a worthwhile step.  This will at least allow one more person to question the changes going in and maybe that's just enough time for monitoring changes that might affect your component.

Unless somebody knows off the top of their head how to go about configuring the Eclispe repos to require a review, I'll take the action to figure it out.

Thanks, Kevin

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/a7R3muaWPzE/unsubscribe.
To unsubscribe from this group and all its topics, 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/bfb14f1a-3eb6-42e7-b225-5be77eebd88f%40googlegroups.com.

[Heiko Braun]

I think requiring at least one review approval before merging code is a worthwhile step.  This will at least allow one more person to question the changes going in and maybe that's just enough time for monitoring changes that might affect your component.

 yes, that certainly reasonable. 

[Ken Finnigan]

If we have admin rights to the repos, not something I've checked, you can basically set "protection" on a branch such that a PR needs to be approved before it can be merged.

We use that feature on all WF Swarm repositories.

--

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.

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/CABH8erksXEnJ4TJ45x3SrrfjeXC0v-rXnTHb5U778E8rTHOb_Q%40mail.gmail.com.

[John D. Ament]

I'm sure its just a request to eclipse webmaster for all existing repos, and then making sure we call it out for all new repos.

I'm supportive of the change, would help make sure everyone is in agreement a bit more.  I just hate that its what we have to stoop to keep the communication flowing.

John

[Kevin Sutter]

Yep, that's what I am finding.  We don't have direct admin capabilities.  If we decide this is the right process, then we'd have to write a Bug Tracker to modify our repos.

--  Kevin

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/e6e3f7ac-d854-4816-916b-ed878ee3fa7e%40googlegroups.com.

[Gordon Hutchison]

+1 Kevin, 

seems to me that a review from a second pair of eyes and brain is a good idea -

as the Microprofile specs and their userbase expands, the argument for this becomes

stronger. With this, we need to continue to make sure that a good PR from a 'lone' or new contributor gets

a review in good time, so that we remain as inclusive and open to good ideas as we have been to date.

Gordon

On Wednesday, 6 September 2017 13:51:49 UTC+1, Kevin Sutter wrote:

Heiko,

I agree that we can't slow every component down just so that us laggers can keep up...  :-)  But, I think requiring at least one review approval before merging code is a worthwhile step.  This will at least allow one more person to question the changes going in and maybe that's just enough time for monitoring changes that might affect your component.

Unless somebody knows off the top of their head how to go about configuring the Eclispe repos to require a review, I'll take the action to figure it out.

Thanks, Kevin

On Wed, Sep 6, 2017 at 3:31 AM, 'Heiko Braun' via Eclipse MicroProfile <microp...@googlegroups.com> wrote:

In general I agree with pretty much everything said here so far, but we need to keep in mind that the subprojects cannot always wait for everyone to provide feedback. Our attention span is limited and we work with different schedules, timezones and external obligations.

I think the case John mentioned describes an implementor trying to keep track with changes in his/her implementation. Maybe this situation can be dealt with otherwise? I.e. compatibility guidelines for releases (breaking changes disallowed between minors) and "official" review phases for RC's that allow implementors to update and adjust? 

I think it would be useful relief the day to day activities of a subproject from these concerns and move to more coarse grained "review" cycles, that everybody can plan for ahead of time. 

Does that make sense?

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/a7R3muaWPzE/unsubscribe.

To unsubscribe from this group and all its topics, send an email to microprofile...@googlegroups.com.

To post to this group, send email to microp...@googlegroups.com.

[Heiko Rupp]

I am a bit late in the game...

I can imagine that there are changes that not only impact the own sub-spec, but others. For example for Metrics we plan to add (post MP 1.2) extension points so hat other specs can easily export their metrics into well-known places. If we (Metrics) change that API, then we need to inform the others about this. As we can't know who uses the API/SPI, posting this on the ML / GGroup would be the best (?).

[Emily Jiang]

I think it is better for all implemenations to register their interest in the corresponding repo with their contact details, as not every one follows every single message in google group. Therefore, "register and notify model" works better, instead of broadcasting:o.

For other cross spec changes, we have to shout loudly in the mailinglist.

Emily

[Ken Finnigan]

Are you suggesting a private email from someone working on a spec to the contact details of "implementors" of that spec regarding a potentially breaking or major change?

What about people who are in the process of implementing but haven't "registered" yet? How do people become aware they need to "register" at all. Do other MP.io specs need to "register" to indicate they're a consumer of another spec?

Now some of the above might be useful information, but I'm not sure we should be expecting people to know that they need to request the ability to see that information as opposed to it being available publicly.

--

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.

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/724b9e27-8659-4dbb-a67f-7f2d5ede9eb7%40googlegroups.com.

[Emily Jiang]

Good questions! Apart from all of the emailing etc, there should be an issue raised on the corresponding repo as well. In each repo, we should have a big notice displayed to say something like "if you plan to implements the spec, please register here so that you are notified for any potential breaking changes".

Only implementors should register as the consumer has a stable version to work with. 

Emily

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.

[David Blevins]

I think the natural outcome of having a private list of implementors is that implementor A sends out a notification and implementor B, who also has permission to send notifications, responds to said notification.  Now we effectively have a private Expert Group list like the JCP pre JSR-348.

I definitely understand the motivation.  I think we’re all feeling the effects of this: (chart is the number of topics per month on this list)

If this trend continues, we will be forced to move to traditional approach of a discussion list per spec.  It’s really a matter of when, not if.  That said, the danger in forking traffic off is it can zap momentum and energy.

My gut would be to wait a bit and see how the topics look post-JavaOne.  I suspect we’re going to see a dip.

-- 

David Blevins

http://twitter.com/dblevins
http://www.tomitribe.com

310-633-3852

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/37365fd2-bcb7-469d-8efe-2dccacf7d634%40googlegroups.com.

[Alasdair Nottingham]

I absolutely agree that the volume is related to MP 1.2 activity for JavaOne and I also expect a dip. I don't like the idea of having private lists. 

Alasdair Nottingham

On Sep 13, 2017, at 10:45 AM, David Blevins <dble...@tomitribe.com> wrote:

I think the natural outcome of having a private list of implementors is that implementor A sends out a notification and implementor B, who also has permission to send notifications, responds to said notification.  Now we effectively have a private Expert Group list like the JCP pre JSR-348.

I definitely understand the motivation.  I think we’re all feeling the effects of this: (chart is the number of topics per month on this list)

<PastedGraphic-1.png>

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/3D5DDCF9-099E-4828-ABD2-392219D26A0F%40tomitribe.com.

[John D. Ament]

David,

I just want to point out.  Presently the FT component is operating in a semi-private fashion.  There appears to be a google hangout where questions and coordination is occurring (not on the google group) as well as individual pings on questions or requests to review.  

I know for me, google hangout is the least reliable means for me to respond.

John

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

[Amelia Eiras]

+1 to avoid "private vacuum working"

Not scalable & nor beneficial to OSS project core values.

Will repeat it as many times as needed, let's stop ourselves, from being "that volunteer" that chooses to get MP stuff done & not elevate others to also own sections of the project that enable them to also execute or complete MP tasks interchangeably.
This feedback goes for every active MicroProfiler, we are doing much better, bc we are a bit more grounded. Be that example of what you expect your peers to be! 💪🏼


Using this thread, I would like to ask any MicroProfiler to avoid pulling me in private MP msgs, that ought to be done public the via gforum.
Clearly, the subject will dictate when a MP MUST private msg needs to take place.

Further, in my case-- if a MP hangout takes place, within 1hr after chat the minutes need to be posted to gforum... is expected as a must action.

Did we ever add it that to How we make data scalable? If not, it needs to be set up so that we don't drop the ball as things are moving fast.

Personally, with anything related to MP private chats, i do ONLY participate in any video calls that when requested do send the written minutes from what call via MP forum. I don't participate nor tolerate privacy on anything MP when not beneficial to our community. It is waistful to be a part of those chats. Zero tolerance.


----

Next Tuesday is the MP hangout, this topic is great & should b added to topics for discussion during call.

See many of you there, 💫

[Mike Croft]

The Metrics specification has been using Gitter very effectively in this regard. There are a number of advantages:

• Low-level detailed discussion can happen more easily with rapid feedback
• It is entirely public (no account needed to view, GitHub account needed to contribute): https://gitter.im/eclipse/microprofile-metrics
• Eclipse already has a community on Gitter + the "rooms" already exist, they just need to be used.

This is *not* a private list of any sort. Anyone is welcome to join and ask questions and get quick feedback. For example, if KumuluzEE was implementing Metrics and wanted to clarify any point of the spec, the Gitter room is the perfect place for that discussion. As David pointed out, the volume of topics in this forum has always been difficult to follow but is now overwhelming.

Each major event/milestone for Metrics is still shared in this Google Group (for example, RC announcements), but the chat from Gitter has allowed us to work together better and more efficiently without negatively affecting everyone else and without making everyone wait for a phone call to ask questions.

[Emily Jiang]

+1 on Gitter. A while ago, I created two rooms: https://gitter.im/microprofile-fault-tolerance/ and https://gitter.im/MicroProfile-config
I tried to use them but I did not get much response, so I used hangout a great deal. I am so sorry if this has made some people feel uncomfortable. Personally I do like gitter. It is like irc-channel and it is better.

I feel sending an email to the mailing list to ask one person in particular to review or chase up review might clatter the conversation. Maybe I was wrong. Perhaps now might be the best chance to agree on the communication channel, e.g. no private emails even if chasing up reviews etc.

If we want to grow as a healthy community,  the most important thing is "no blame" culture. If something is not right, just shout and reach general consensus and change.


We can do a retrospective meeting to review the community process.

Emily

[Mike Croft]

On Thursday, 14 September 2017 10:29:44 UTC+1, Emily Jiang wrote:

+1 on Gitter. A while ago, I created two rooms: https://gitter.im/microprofile-fault-tolerance/ and https://gitter.im/MicroProfile-config
I tried to use them but I did not get much response, so I used hangout a great deal. I am so sorry if this has made some people feel uncomfortable. Personally I do like gitter. It is like irc-channel and it is better.

It's probably better to use rooms within the Eclipse community because they will be automatically linked to GitHub and have all sorts of nice integrations with issues and PRs etc. I created a new PR for Metrics to add a "chat with Gitter" badge to the README so that people can easily spot it and join in the discussion:
https://github.com/eclipse/microprofile-metrics/pull/143

We could use Gitter for other things too - for example, a lot of us will be at JavaOne and Gitter is a nice place to coordinate people for the Eclipse booth or for events. We could create eclipse/microprofile-events or something (to avoid confusion with the conference app repository)

[Emily Jiang]

+1 on Mike's idea!

yep. We should have a round table discussion on the process during JavaOne. 

Emily

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/a7R3muaWPzE/unsubscribe.
To unsubscribe from this group and all its topics, 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/7217c349-e39e-404e-866f-ddf065df221a%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

Thanks
Emily
=================
Emily Jiang
eji...@apache.org

[Kevin Sutter]

Thank you, Mike, for bringing up the constructive idea of using gitter.  +1.  I have not personally used it yet, but I have heard good things from my local IBM team members.  I would encourage it's use for team-related conversations.  And, of course, bring up project-wide topics on the Google Group.  Thanks again!

Just to test it out, I created a room for the microprofile-bom component.

1. Go to https://gitter.im/
   
2. Sign in with your github account
3. Go to https://gitter.im/eclipse
4. Click on "Add a Room"
5. Select "Eclipse" as the Community
6. Select or type the name of your room (eclipse/microprofile-bom in my case)
7. Done -- you can invite specific people to initiate a conversation, but it is all public
   

--  Kevin

[Kevin Sutter]

<vent>
It really frustrates me when constructive dialog is interrupted by a left turn...  And, since this "left turn" was directed at some "private conversations" involving me, I feel I should respond and defend the FT team...

The Fault Tolerance team and, specifically, Emily are not trying to do anything in the private.  They do hold regular Google Hangouts per the MP Calendar (https://calendar.google.com/calendar/embed?src=gbnbc373ga40n...@group.calendar.google.com&ctz=GMT&pli=1).  This is a pretty standard practice for all of the teams, including the overall Project.  The discussions on these hangouts normally end up as Issues and/or new threads on the Google Group.  Nothing is deliberately being done in the "back room" to hide anything from anybody.  These hangouts just make it easier to make progress on difficult topics (verbal is easier than typing).

And, even more specific to the individual pings or requests for reviews...  Yes, Emily did reach out to me directly, as a co-worker and as a co-lead of the MicroProfile project.  She is trying like most everybody on this extended team to finalize a component release before JavaOne.  There was a minor Issue 144 and associated PR to change the maxDuration to 60 seconds.  She had requested a review, but John was not able to respond for whatever reason (no big deal).  She asked me what other options she had since she didn't want to merge the changes without a review.  And, she's trying to complete the FT 1.0 release.  I offered to review.  I reviewed the Issue, saw that John had suggested a new default of 60 seconds, and Emily went with it.  Pretty simple change, I approved it and Emily merged the change.

I don't see anything out of the ordinary in that process.  We invite multiple people to review a PR because we know that people get busy.  As long as we're comfortable with the review that was held, we should be allowed to go forward without waiting for every last person to review.  If we did that, we'd be stuck.  I know this same situation has happened to me in the past.  I get invited to review a PR along with several other people.  I was busy and didn't get around to it until after the fact.  If something with the PR doesn't sit right with me when I finally get to review it, I re-open the discussion to see whether another PR might be warranted.  Just normal open-source development.  Not everybody can be expected to be available 100% of the time.

Bottom line is that I don't see the issue with how Emily handled this particular situation.  She was trying to make progress, but didn't want to cut corners.  She came to me for advice and I provided some assistance.  Other than the fact that Emily has pretty much 24/7 access to me because of where we both work, I don't see anything out of the ordinary.  Neither of us tried to cut corners or remove anybody from the process.  We can bring this up at the next Project Hangout, but I really don't know what else we're going to say -- other to reiterate and emphasize public communications.  But, I think we're all doing that to the best of our abilities.

</vent>

-- Kevin

[John D. Ament]

Kevin,

If you think anything about my comment is directed to you, we're pretty far off course.  I'm actually completely unaware of anything you're doing with regard to Fault Tolerance.

There are a number of things I see within FT specifically that I don't see in other specs, and really all I'm trying to point out is there's room for improvement (thinking in an agile way, we iterate and retrospect on learnings to come up with better ways).  It's very possible that  these things are happening in other specs, just not visible enough to be detected.  For instance, this is the first I'm seeing Gitter being mentioned (it's not a bad idea, and still keeps the async nature).

When I refer to hangouts, I'm not referring to the scheduled meetings.  I'm talking about private conversations that pop up in Gmail/Inbox (that replaced the old Google Talk feature).  These conversations are not brought back to these lists, don't surface as tickets in github issues, or even in pull request comments.  Here's an interesting for instance - https://github.com/eclipse/microprofile-fault-tolerance/pull/138/files - there's no associated ticket, as best as I can tell from looking at it all its doing is removing tests, and when asked why this was happening there's no answer.  The pull request is merged too quickly for anyone to ask the question - is this the right thing to do?  I'm not certain this was discussed on a hangout or some other means.

John

On Thursday, September 14, 2017 at 9:07:29 AM UTC-4, Kevin Sutter wrote:

<vent>
It really frustrates me when constructive dialog is interrupted by a left turn...  And, since this "left turn" was directed at some "private conversations" involving me, I feel I should respond and defend the FT team...

The Fault Tolerance team and, specifically, Emily are not trying to do anything in the private.  They do hold regular Google Hangouts per the MP Calendar (https://calendar.google.com/calendar/embed?src=gbnbc373ga40n0tvbl88nkc3r4@group.calendar.google.com&ctz=GMT&pli=1).  This is a pretty standard practice for all of the teams, including the overall Project.  The discussions on these hangouts normally end up as Issues and/or new threads on the Google Group.  Nothing is deliberately being done in the "back room" to hide anything from anybody.  These hangouts just make it easier to make progress on difficult topics (verbal is easier than typing).

[Amelia Eiras]

Night/Morning #MicroProfilers, 

On June 5th thread subject: INFRA question: is there a preferred communication tool used by Eclipse projects?  was created with Wayne cc'd. It had 18 views and 5 participants, easy to miss. Thread discusses Gitter. :) 

• https://groups.google.com/forum/#!topicsearchin/microprofile/amelia;context-place=forum/microprofile/microprofile/5lNV5La_0MM
  

Please consider that thread a valuable extension to topic!

A.

[Kevin Sutter]

Thanks, John, for the further clarification.  I was off-base on my interpretations of the private messaging and the google hangout references.

I will also agree with your question about that particular PR.  I will mention that I sometimes miss items like that as well, but common courtesy would be to reply to questions like that.  Looking for some reasoning on the removal or adjustment of those tests is a fair question.  We should continue to encourage our extended teams to participate fully with these Issue and PR conversations.

Thanks again for your help and for putting up with my <venting>...  :-)

--  Kevin

On Thu, Sep 14, 2017 at 8:57 PM, John D. Ament <john.d...@gmail.com> wrote:

Kevin,

If you think anything about my comment is directed to you, we're pretty far off course.  I'm actually completely unaware of anything you're doing with regard to Fault Tolerance.

There are a number of things I see within FT specifically that I don't see in other specs, and really all I'm trying to point out is there's room for improvement (thinking in an agile way, we iterate and retrospect on learnings to come up with better ways).  It's very possible that  these things are happening in other specs, just not visible enough to be detected.  For instance, this is the first I'm seeing Gitter being mentioned (it's not a bad idea, and still keeps the async nature).

When I refer to hangouts, I'm not referring to the scheduled meetings.  I'm talking about private conversations that pop up in Gmail/Inbox (that replaced the old Google Talk feature).  These conversations are not brought back to these lists, don't surface as tickets in github issues, or even in pull request comments.  Here's an interesting for instance - https://github.com/eclipse/microprofile-fault-tolerance/pull/138/files - there's no associated ticket, as best as I can tell from looking at it all its doing is removing tests, and when asked why this was happening there's no answer.  The pull request is merged too quickly for anyone to ask the question - is this the right thing to do?  I'm not certain this was discussed on a hangout or some other means.

John

On Thursday, September 14, 2017 at 9:07:29 AM UTC-4, Kevin Sutter wrote:

<vent>
It really frustrates me when constructive dialog is interrupted by a left turn...  And, since this "left turn" was directed at some "private conversations" involving me, I feel I should respond and defend the FT team...

The Fault Tolerance team and, specifically, Emily are not trying to do anything in the private.  They do hold regular Google Hangouts per the MP Calendar (https://calendar.google.com/calendar/embed?src=gbnbc373ga40n0tvbl8...@group.calendar.google.com&ctz=GMT&pli=1).  This is a pretty standard practice for all of the teams, including the overall Project.  The discussions on these hangouts normally end up as Issues and/or new threads on the Google Group.  Nothing is deliberately being done in the "back room" to hide anything from anybody.  These hangouts just make it easier to make progress on difficult topics (verbal is easier than typing).

And, even more specific to the individual pings or requests for reviews...  Yes, Emily did reach out to me directly, as a co-worker and as a co-lead of the MicroProfile project.  She is trying like most everybody on this extended team to finalize a component release before JavaOne.  There was a minor Issue 144 and associated PR to change the maxDuration to 60 seconds.  She had requested a review, but John was not able to respond for whatever reason (no big deal).  She asked me what other options she had since she didn't want to merge the changes without a review.  And, she's trying to complete the FT 1.0 release.  I offered to review.  I reviewed the Issue, saw that John had suggested a new default of 60 seconds, and Emily went with it.  Pretty simple change, I approved it and Emily merged the change.

I don't see anything out of the ordinary in that process.  We invite multiple people to review a PR because we know that people get busy.  As long as we're comfortable with the review that was held, we should be allowed to go forward without waiting for every last person to review.  If we did that, we'd be stuck.  I know this same situation has happened to me in the past.  I get invited to review a PR along with several other people.  I was busy and didn't get around to it until after the fact.  If something with the PR doesn't sit right with me when I finally get to review it, I re-open the discussion to see whether another PR might be warranted.  Just normal open-source development.  Not everybody can be expected to be available 100% of the time.

Bottom line is that I don't see the issue with how Emily handled this particular situation.  She was trying to make progress, but didn't want to cut corners.  She came to me for advice and I provided some assistance.  Other than the fact that Emily has pretty much 24/7 access to me because of where we both work, I don't see anything out of the ordinary.  Neither of us tried to cut corners or remove anybody from the process.  We can bring this up at the next Project Hangout, but I really don't know what else we're going to say -- other to reiterate and emphasize public communications.  But, I think we're all doing that to the best of our abilities.

</vent>

-- Kevin



On Wednesday, September 13, 2017 at 6:09:17 PM UTC-5, Amelia Eiras wrote:

+1 to avoid  "private vacuum working"

Not scalable & nor beneficial to OSS project core values.

Will repeat it as many times as needed, let's  stop ourselves, from being "that volunteer" that chooses to get MP stuff done & not elevate others to also own sections of the project that enable them to also execute or complete MP tasks interchangeably.
This feedback goes for every active MicroProfiler, we are doing much better, bc we are a bit more grounded. Be that example of what you expect your peers to be! 💪🏼


Using this thread, I would like to ask any MicroProfiler to avoid pulling me in private MP msgs, that ought to be done public the via gforum.
Clearly, the subject will dictate when a MP MUST private msg needs to take place.

Further, in my case-- if a MP hangout takes place, within 1hr after chat the minutes need to be posted to gforum... is expected as a must action.

Did we ever add it that to How we make data scalable? If not, it needs to be set up so that we don't drop the ball as things are moving fast.

Personally, with anything related to MP private chats,  i do ONLY participate in any video calls that when requested do send the written minutes from what call via MP forum. I don't participate nor tolerate privacy on anything MP when not beneficial to our community. It is waistful to be a part of those chats. Zero tolerance.


----

Next Tuesday is the MP hangout, this topic is great & should b added to topics for discussion during call.

See many of you there, 💫

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/a7R3muaWPzE/unsubscribe.
To unsubscribe from this group and all its topics, 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/d890fc7a-4cdd-48da-9ff4-0b8c8fcaaebe%40googlegroups.com.

[John D. Ament]

Amelia,

FYI, that link doesn't work (or at least it doesn't give a very obvious response).

John

[Amelia Eiras]

Apologies everyone.  John please try:

https://groups.google.com/forum/#!searchin/microprofile/$20INFRA$20question$3A$20is$20there$20a$20preferred$20communication$20tool$20used$20by$20Eclipse$20projects$3F$20%7Csort:relevance/microprofile/5lNV5La_0MM/WUOUx_nYAAAJ

Happy wknd all, 

Amelia Eiras 

https://twitter.com/ameliaeiras

http://www.tomitribe.com

https://www.tomitribe.io

--
You received this message because you are subscribed to a topic in the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/microprofile/a7R3muaWPzE/unsubscribe.

To unsubscribe from this group and all its topics, 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/596bef0c-a91f-4b1d-ad86-8de86a3b5ae0%40googlegroups.com.

[David Blevins]

On Sep 15, 2017, at 6:34 AM, Kevin Sutter <kwsu...@gmail.com> wrote:

Thanks again for your help and for putting up with my <venting>...  :-)

As a habit in life I personally am always happier people say what they need to say rather than let it boil.  As long as we’re patient with each other it’s usually a short term bump for a long term jump.

-David