On Wed, Jun 28, 2017 at 11:35 AM, Romain Manni-Bucau <rmannibu...@gmail.com> wrote:
> 2017-06-28 11:39 GMT+02:00 Jonathan Gallimore < > jonathan.gallim...@gmail.com> > : > > > Wow. > > > > Well, thanks for writing the email, and starting the discussion. From > where > > I'm sitting, it looks like there are a few issues. I'll work in > reverse-ish > > order (in terms of your post). > > > > -- Reverting commits. > > > > I've seen the reverts - I also note that other than on a JIRA ticket, > there > > was zero conversation on the dev@ list. This isn't the first time that > > this > > has happened, and in my opinion, is fundamentally wrong. If there is a > > genuine need to revert something, you need to post to the dev@ list, > call > > out the commit, and say why it needs reverting. The person proposing the > > revert should be prepared to have a should we "roll-back or fail-forward" > > conversation in the community, and not simply take it upon themselves to > > make that choice. Folks might be wondering why we need to do this (I > think > > there is a perception that their mail might not be read, so why bother > > posting) - reasons are simple: > > > > * Encourage discussion and contribution - discuss the specific issues. > What > > stopped working? Does the committer know what they broke, or what the > > reason for proposing a roll-back is > > * Co-ordinate - if something breaks in a commit, deciding who's going to > > help fix what might be better than rolling back > > * Educate - is there a process where something in staging becomes live > > automatically? Is that what we tried to avoid this time? Is there a > better > > way to build the site and stage it for peer review? > > > > FYI > http://tomee-openejb.979440.n4.nabble.com/Fwd-svn-commit-r18 > 00091-in-tomee-site-trunk-content-content-admin-content-admi > n-cluster-content-admi-td4681967.html > was intented to host that discussion (and not pollute jira) > > Note that it is what happent most of the time, not sure why these dev mails > are missed. > That's now been pointed out to me twice since I posted this. Actually saw and read that post before posting. If you think that constitutes a clear discussion, and justifies your actions - sorry, but I'm afraid I could not disagree more: * You replied to commit. Yes that hits the dev@ list, but was the shortest possible thing you could have done, and in reality had almost no visibility. However, you didn't change the title, so at a glance, its hard to distinguish from the commit messages themselves. To answer your question - this is most probably why they are missed. Do you really think "Fwd: svn commit: r1800091 - in /tomee/site/trunk: content/ content/admin/ content/admin/cluster/ content/admin/configuration/ content/advanced/ content/advanced/applicationcomposer/ content/advanced/client/ content/advanced/jms/ content/advanced/shading/ co..." is a good subject? How about "Please don't push these website changes to production". Or "[DISCUSS] [REVERT] breaking website change"? * Your single line message "Please don't publish this, it breaks existing links which is pby sthg we don't want to do now. Pinged Ivan about it", tells us very little. You make no mention that you intend to revert it, and very minimal information on what the issue is. How are we supposed to discuss it if we don't know what the issue is? Side note - I don't know how well people with less English knowledge get on with the abbreviation of "probably something". This is just a suggestion, but I'd avoid the abbreviation of those words on your already very short message. * You "pinged" Ivan - privately, I assume. I have no visibility of that. Why not just post it on dev@ and have the discussion in the open. Maybe we'll all learn and improve and collaborate as a result. Maybe we'll appear as a more welcoming community. The private conversation is exactly what we should avoid. * If I have read commit emails correctly, your revert (which actually shows _before_ your post to dev@ in my mailbox, by the way), your revert commit happened within 60 seconds of your post. Not exactly a lot of time to enable a conversation, is it? > > > > > > All of the above potential (and that's just off the top of my head, I'm > > sure there is more) was lost by the 'silent revert'. The view the > committer > > / contributor has becomes "my stuff was rejected without comment and > > without discussion, why should I bother?" and the damage to community > > starts / continues. In my opinion, simply reverting commits without > > appropriate discussion on dev@ needs to stop, right now. We need to > > nurture > > contributions, not simply reject them. > > > > I saw one point about breaking the build, and the build not being fixed > > quickly enough. Again, I think that needs to be called out and discussed > > how to fix (rollback or fail-forward), as opposed to commits being > rejected > > or reverted without discussion. It also needs to be understood and > accepted > > that we will need to have that sort of conversation each time it happens. > > Even if a change breaks something, I don't think anyone should have > "carte > > blanche" to revert commits without discussion on dev@. > > > > -- Making changes. > > > > So let's talk about the elephant that isn't in the room. Simply put, > there > > isn't enough discussion on dev@ and there is virtually no peer review at > > all. Andy, I wasn't aware that you'd be pushing stuff to staging, and so > > those commits, from where I was sitting, came out of the blue. I will > note > > that there was some discussion around TomEE documentation, which is > great, > > but the commits I saw were so big that I couldn't get a diff of them. I > > will go through and review, but that is going to take some time. At the > > moment, I don't know what the changes were so I can't really comment on > the > > specifics. There was no invitation to review or discuss. There was no > > discussion around the process of building a local copy of the website and > > maybe staging it somewhere else to facilitate that review. The > > documentation on contributing to the website and review changes is, I > > suspect, somewhat lacking. > > > > raw doc to do an update/submit a patch is > http://svn.apache.org/repos/asf/tomee/site/trunk/generators/ > site-tomee-ng/README.adoc > > then it is just a matter of synching target/site-tomee-ng* with content/ of > the site (pubsub). We can surely setup pubsub mvn plugin to make it > smoother if needed. > Here's what I found on tomee.apache.org: http://tomee.apache.org/community/ index.html. The information in that .adoc would be useful on an actual page on the website. > > > > > > You mention that you were mentoring a contributor - you don't mention > who, > > but I'm assuming its Ivan Junckes for a bunch of reasons, but mostly > > because of his conversations on the TomEE documentation thread. Please > > correct me if I'm wrong. Anyway, whoever it is, we'd love to see more > > contributions from you. I understand that this negative experience might > > leave a bad taste, but it would be great if you bear with us and please > > carry on - I am very hopeful that we can improve, and in turn, enable you > > to contribute more and help the community grow. We would appreciate your > > feedback to help us do so. > > > > While I saw some patches attached to the JIRA, I think a better process > > would have been to have contributor talk about their patch on dev@, how > to > > build it and review, and what what the changes are. It seems like we're > > relying on JIRA heavily, almost as a replacement for this mailing list - > > that should stop too. Discussions should happen on dev@ and give people > > the > > chance to respond. One side note on that - I really don't want to see a > lot > > of "lazy consensus", where "I didn't get a reply in 72 hours and 1 second > > so clearly everyone agrees" - if you get no replies - follow up. Provide > > more information. Ask what people need to make replying easier. Do they > > need a test to run, or a simple command to execute? More description? A > > report showing library changes? A copy of the website running somewhere > to > > review? The easier it is to reply, the quicker the responses will be. > Also > > accept that people may just *need more time*. Like many, I have a busy > > full-time job, and invariably I sometimes have to work a bit extra at > that. > > I also have two demanding kids to entertain, feed and put to bed. Things > > seemed so much simpler back in 2007, as I had more time. I'll do > anything I > > can, but a 72 hour deadline is sometimes just not long enough. > > > > As an example of discussing before committing, I proposed a patch here: > > http://tomee-openejb.979440.n4.nabble.com/MDB-JMX-Control-td4681962.html > - > > I have had a couple of items of feedback (thank you Romain and > Jonathan!). > > I now need to follow up on that discussion, update my patch and push the > > discussion on again, whilst also trying to obtain some more views for the > > discussion. I have another patch which is a little more complex which > I'll > > be proposing today as well. Please note that I am not saying I am > perfect, > > and I am not saying those conversations are perfect either, but hopefully > > they provide something to think about and improve upon. > > > > It is best done this way but I think - correct me if wrong - it is fine to > push something you think right (speaking of SNAPSHOT, not the website for > the already mentionned reasons) and then got a ping on the list saying "hey > man you broke something, if you dont fix it now i'll revert it and we'll > see how to add it back". We all do it on our free time so I tend to > encourage action and hard fixes when needed than list "idling" which often > happens. > > > > > > So, in summary (TL;DR if you like): > > > > * Propose rollbacks on the dev@ with reasons. If you had to -1 > something, > > you need to give a visible reason - same should apply here > > * More discussion on dev@ before commiting > > * Encourage contributors to present their proposed changes and discuss > > their diffs on dev@ > > * Don't rely on JIRA comments for discussions - if it didn't happen on > the > > mailing, it didn't happen. > > > > Except the second point it sounds good - but thinking about it this 2nd > point can need some classification like "bug fix", "regression fix", "new > feature", "spec impl" or anything enabling to judge if a discussion is > needed or not. > You mean "* More discussion on dev@ before commiting" comment? Whether it'll actually happen or not, well, we'll see. In terms of my opinion, I'm not going to budge on it. Even for a simple change like a dependency update or a little bugfix, you can throw out a little heads-up on dev@, and check no one objects. Its not hard and doesn't need to take a lot of time. > > Also think the first point need its corollar: don't apply a diff which is > under discussion on the list until it got ack by this discussion. > Not applying the diff without review is covered by my second point ("* More discussion on dev@ before commiting"). I also stand by my first point. Andy committed something which you had an issue with. You went and wiped it out with virtually zero discussion, and no replies. Sometimes people make mistakes, and break stuff. If happens. Sometimes they omit to post on the mailing list, whether that omission is intended or not. You had the opportunity to be a "bigger man" and help promote the discussion and build the community. You didn't take it, you instead chose to simply revert. Jon > > > > > > I hope that my views above are seen as reasonable, balanced and helpful > > (which is my intent, and how I hope it comes across). > > > > Andy, thanks for kicking off this conversation, I too, hope there will be > > some good, considered, responses on here. Also thank you for taking the > > time to work on the documentation with another contributor (Ivan?) - and > > thank you to them too. > > > > Jon > > > > On Wed, Jun 28, 2017 at 1:14 AM, Andy Gumbrecht < > agumbre...@tomitribe.com> > > wrote: > > > > > I'm writing this on the public dev list as there seems to be inaction > on > > > the private list regarding the preservation and nurturing of > > contributions > > > to the TomEE project. I hope this serves as an entry into a public > > > discussion on how to improve or resolve the situation. > > > > > > This evening (and late into the night) I was working in my free time > > > together with another contributor in an effort to improve the currently > > > very poor TomEE website. This work was offsite, and being pushed to > > staging > > > for peer review. > > > > > > It became apparent that another committer deemed it in some way > > acceptable > > > to trash this effort 'during' this work without any collaboration > simply > > > because they disagree with some of the changes, even when those changes > > had > > > not been finalised. The existence and state of the JIRA ticket was > > > completely disregarded by this committer. > > > > > > This is not the first time that a committer has performed such arrogant > > and > > > destructive actions on other peoples contributions to the project. Such > > > actions are always extremely disrespectful at a personal level. This is > > of > > > course reflected by the state of the community that currently feels > void > > of > > > any participation specifically due to this kind of mobbing. It has > become > > > virtually impossible for contributors to perform any work on the > project > > > without almost instant negative, rather than positive or nurturing, > input > > > at every level (even documentation). I know of several potential > > > contributors who have avoided the project due to this currently very > > > predictable attitude. It has in fact almost become a joke within other > > > communities. > > > > > > Maybe speaking for others, it is no secret that some committers do not > > get > > > along with others due to these reasons. However, I do value the immense > > > contribution by every committer to the TomEE project and understand > each > > > individuals value and rights to and on the project. This does not mean > > that > > > one individual is the owner of this project (we all are) and has the > > right > > > to overwrite or trash other peoples work in progress, no one should > ever > > > have that sole right. Well actually we all do, and this seems to be the > > > fundamental problem. > > > > > > We desperately need to instigate some measures to prevent the further > > > demise of the TomEE community by individuals that seem intent on > breaking > > > it for reasons that go beyond me (well actually they don't, but that's > > > another story). I believe that there was a past discussion on > > introducing a > > > 2 or 3 plus one workflow into the the project, whereby all commits must > > > undergo a peer review. This may somewhat stifle rapid development, but > on > > > the other hand it would ensure that commits are stable and not open to > > > trashing by others. > > > > > > Given that the current JIRA practice is now to commit before creating > the > > > actual issue (which has been encouraged by the overly aggressive > > > environment), the peer review system would also return that process > back > > to > > > a normal and acceptable state. Therefore I would like to suggest we > begin > > > taking the necessary steps for the introduction of this process. > > > > > > Looking forward to some candid responses. > > > > > > Best regards, > > > > > > Andy. > > > > > > > > > -- > > > Andy Gumbrecht > > > https://twitter.com/AndyGeeDe > > > http://www.tomitribe.com > > > > > >
