Actually, I have seen some real benefits of on-line conferencing. These benefits are similar to conferences and meetups.
It is clear that the way you have to do these things is *in*addition* to the normal email discipline, but the addition can really be positive in that quiet lurkers on the mailing list can sometimes be interactive in an online conference and be encouraged. That leads to better involvement in other aspects of the project. I do think that a bit of diversity in *when* the on-line conferencing is done can be very helpful for time zone inclusiveness. On Wed, Nov 11, 2015 at 10:16 AM, Joe Witt <joe.w...@gmail.com> wrote: > "Trust is the basis of a healthy community" > > -- For sure. > > "and RTC (via Jira or otherwise) just screams "we don't trust you. we > must review all commits first."" > > -- I disagree. RTC has merit independent of concerns of trust. If > trust issues are present in a community then any number of challenges > will exist and all processes will suffer. Keep in mind RTC applies to > everyone (PMC, committer, contributor). So it isn't about trust at > all. It is about community. > > Not wanting to sidetrack this thread but also didn't want that comment > to go without a counter. > > Thanks > Joe > > On Wed, Nov 11, 2015 at 12:59 PM, Greg Stein <gst...@gmail.com> wrote: > > On Wed, Nov 11, 2015 at 6:27 AM, Steve Loughran <ste...@hortonworks.com> > > wrote: > > > >> > >> > On 11 Nov 2015, at 09:38, Bertrand Delacretaz <bdelacre...@apache.org > > > >> wrote: > >> > > >> > Hi Steve, > >> > > >> > On Tue, Nov 10, 2015 at 9:31 PM, Steve Loughran < > ste...@hortonworks.com> > >> wrote: > >> >> ...is JIRA-first development conducive to developing a community?... > >> > > >> > I don't think so, as you say this breaks the project into very small > >> > buckets and it's very hard for someone new to get the overview of > >> > what's going on and what the big ideas and visions are. > >> > > > > Agreed. > > > > I also find it sad that work is *gated* by using Jira first. We should be > > trusting our peers, let them commit changes necessary, and review their > > work afterwards. Trust is the basis of a healthy community, and RTC (via > > Jira or otherwise) just screams "we don't trust you. we must review all > > commits first." > > > >>... > > > >> One of the troublespots is those "minor" patches which have traumatic > >> consequences; you don't notice when the issue is created, don't watch > it, > >> and then, when its merged in, you discover that things now behave > >> differently. Anything related to specific dependency updates are things > to > >> watch there (guava, jackson, jersey), but it could be something more > subtle > >> like a change in the concurrency model of some bit of code. It's only > later > >> that you find your code has stopped working and you are left trying to > work > >> out what happened and why. > >> > > > > I'm not sure what the above has to do with issues/Jira. Any commit can > have > > this effect, whether it was done directly or via an issue. It's just a > > typical problem with development. > > > > (and yeah, it leads into a whole separate conversation about testing and > CI) > > > >>... > > > >> Noted, but we're going to try it in the slider dev group anyway, so we > can > >> do some more detailed code review of various complex things more > >> interactively. I know it excludes people who can't be there, but its > still > >> more inclusive of > >> > > > > I see no problem doing code reviews this way, as other devs can still > > comment/review whatever output gets committed. They're only "shut out" of > > the first review, not ALL review. > > > > Using them for initial code development or decisions? Not so much. > > > > Using them to reach a consensus among a subset of the community? Sure, > and > > bring that result to the dev@ list to reach full community consensus. We > > see this done all the time with hackathons: the group at the 'thon come > up > > with some idea they all like, and bring that to the dev@ list. 10 people > > think it is the right approach and share it, then rope in the other 10. > > > >>... > > > > Cheers, > > -g > > --------------------------------------------------------------------- > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org > For additional commands, e-mail: general-h...@incubator.apache.org > >
