> > More generally, the criteria that the ASF looks for in communication > channels used by projects are (in no particular order): > - open to all > - asynchronous > - available off-line > - full history > - searchable > - archived on ASF controlled systems > - low bandwidth / minimal system requirements
Cannot agree any more. Recently I studied the Apache way from Shane's website [1], now I understand how ASF weight mailing-list as the major communication channel so much. We could stick to mailing list but let's be open to find alternative way which is better. PS I see there is a Dubbo session at ApacheCon NA. I'd be more than > happy to sit down with anyone that is interested and chat about any > questions, concerns, etc. they may have about how the ASF works, why > things are the way the are and any other ASF related questions. Jun and I will attend ApacheCon NA this time. I think it is a good chance for us to meet together to explain the challenge we face to attract developers in China to involve in a project running in the Apache way. 1. http://theapacheway.com/ On Sun, Aug 19, 2018 at 6:22 AM Mark Thomas <[email protected]> wrote: > On 18/08/18 10:24, Ian Luo wrote: > > Mark, > > > > Here's one relevant topic I would like to discuss with you. I understand > > the Apache way encourages *open* discussion. In my opinion, the > interaction > > on GitHub issue is one kind of the open discussion, and many modern open > > source projects leverages this as the major channel. What's your opinion > on > > this? > > From an ASF perspective there are no concerns if that is how a project > prefers to communicate (primarily because all the discussion is echoed > back to an ASF mailing list). > > Personally, it isn't my favourite but I think that is more to do with > how it is integrated into ASF mailing lists than anything else (ASF > mailing lists are the primary way I follow what is going on across > multiple areas of the ASF). I don't like the way questions, bugs and PRs > all end up in the same place and the lack of threading makes it hard to > follow - especially with a high activity project like Dubbo. > > One of the things on my TODO list for ApacheCon NA is to sit down with > the infra folks and figure out if we can improve the integration - > particularly the threading. > > More generally, the criteria that the ASF looks for in communication > channels used by projects are (in no particular order): > > - open to all > - asynchronous > - available off-line > - full history > - searchable > - archived on ASF controlled systems > - low bandwidth / minimal system requirements > > E-mail may seem a little 'old school' at times but it is one of the few > technologies that meets all of the above. Which is why most of our > systems are configured to echo stuff back to the relevant mailing list. > > These days I'm used to an always on internet connections with speeds in > the 10s of megabits where I don't need to worry about the cost (even > when I am out and about) but it is worth remembering that not everyone > is in that position. It wasn't really that long ago that I could > sometimes be found working on Apache projects via a 9600 bits per second > dial-up connection that I paid for by the second. It was perfectly > possible for me to follow what was going on by connecting for a few > minutes every couple of hours, syncing my email, making a few commits if > I had anything to commit and then disconnecting and continuing to work > off-line. If all communication had happened via a GitHub like interface > there is no way I would have been able to follow the project. > > Cheers, > > Mark > > PS I see there is a Dubbo session at ApacheCon NA. I'd be more than > happy to sit down with anyone that is interested and chat about any > questions, concerns, etc. they may have about how the ASF works, why > things are the way the are and any other ASF related questions. > > > > > > Thanks, > > -Ian. > > > > On Sat, Aug 18, 2018 at 10:31 AM jun liu <[email protected]> wrote: > > > >>> > >>> To provide some examples: > >>> > >>> I am employed by Pivotal and Pivotal employs the committers on the > >>> Spring Boot project which embeds Apache Tomcat. From time to time I > >>> receive a work e-mail, slack message or similar along the lines of "We > >>> think we have found a bug in Tomcat. Can you look at it?". My response > >>> is invariably "Sure. Please create an issue in the Tomcat issue tracker > >>> and I'll take a look." > >>> > >>> I also receive direct email from Tomcat users asking for help with an > >>> issue they are having. This happens often enough that I have a e-mail > >>> template for the reply that directs them to ask their question on the > >>> users@ mailing list. > >> > >> These examples impressed me a lot, actually, I am experiencing this now. > >> People from work sometimes report issues about Dubbo through internal > >> communication channels (IM or work email). And I have to admit that in > some > >> cases, I have chosen to directly discuss problems with them but forgot > to > >> bring them to the community, which means I misused the two roles of work > >> and open source. > >> > >> Most of the times, language becomes the excuse for making the wrong > >> decisions, because some colleagues and users of Dubbo in china are not > good > >> enough in English. For those users, maybe we can encourage them to > provide > >> both the Chinese and English descriptions when reporting issues, for > >> example, write the Chinese version first and then directly translate to > >> English using Google. > >> > >> I think that the way Mark's been doing is right for running an open > source > >> project, I will also try to “Redirect everyone reporting issues to the > >> mailing list or Github issue tracker". > >> > >> Best regards, > >> Jun > >> > >>> On 16 Aug 2018, at 19:17, Mark Thomas <[email protected]> wrote: > >>> > >>> On 15/08/18 14:09, Jerrick Zhu wrote: > >>>> Hi, mark > >>>> > >>>> Sorry for disturbing all of you. > >>> > >>> No need to apologise. The additional traffic wasn't, and isn't, a > >> concern. > >>> > >>> My concern was that it appeared that there was some sort of > organisation > >>> going on that the project wasn't aware of. > >>> > >>> A secondary concern was that multiple teams seemed to be writing PRs > for > >>> the same issue. > >>> > >>>> This is an activity for students to participate in open source > project, > >>>> it's held by department named BaiJi, Alibaba. They came us and asked > us > >>> > >>> If by us, you mean "the Alibaba employees who work on Dubbo" then that > >>> request should have been redirected to the Dubbo community - which > means > >>> the dev@ mailing list. > >>> > >>> If by us, you mean "the Dubbo community" then I don't recall seeing > that > >>> request on this list. > >>> > >>> My concern here is that folks appear to have mixed up their "employee" > >>> hat and their "Apache committer" hat. It is easy to do and so is > >>> something to keep in mind. A good general rule is that whenever you > find > >>> yourself discussing anything related to the project at work (or > anywhere > >>> that isn't the project mailing lists), ask yourself "Why isn't this on > >>> the dev@ list?". In my experience it is nearly always the case that > the > >>> conversation needs to move to the mailing list. > >>> > >>> To provide some examples: > >>> > >>> I am employed by Pivotal and Pivotal employs the committers on the > >>> Spring Boot project which embeds Apache Tomcat. From time to time I > >>> receive a work e-mail, slack message or similar along the lines of "We > >>> think we have found a bug in Tomcat. Can you look at it?". My response > >>> is invariably "Sure. Please create an issue in the Tomcat issue tracker > >>> and I'll take a look." > >>> > >>> I also receive direct email from Tomcat users asking for help with an > >>> issue they are having. This happens often enough that I have a e-mail > >>> template for the reply that directs them to ask their question on the > >>> users@ mailing list. > >>> > >>>> to > >>>> provide some simple issues that students can fully engage OS project, > >> and > >>>> we agreed. We also wants more guys to join Dubbo, to contribute. > >>> > >>> Please be aware that some people read "guys" as referring exclusively > to > >>> men. I recommend that you try to use a more inclusive term. I tend to > >>> use "folks". "people" usually works as an alternative as well. > >>> > >>> I do think this is an excellent way to increase interest in Dubbo and > >>> expand the community. Please don't take anything I am saying as > >>> discouragement of this effort. I am fully supportive of it. > >>> > >>>> Now we have noticed that the PRs came together and generate so many > >> emails, > >>>> which had disturbed you. We will consider other more effective ways, > >> such > >>>> as one team fix issues separated from each other. > >>> > >>> It bears repeating. The volume of email was not a concern. It was the > >>> appearance of some sort of organisation of project effort going on that > >>> the project community was not aware of. That rings alarms bells for me > >>> in my role as a mentor. > >>> > >>> Regarding separating issues between teams, there are pros and cons of > >>> multiple teams trying to fix the same issue. The work might be > >>> duplicated but, equally, they might learn from the different approaches > >>> that the other teams took. I don't have a view one way or the other. > All > >>> I suggest (and this is more for the people managing the students) is > >>> that the issue is thought about to ensure that the students get the > best > >>> possible experience. > >>> > >>>> Do you guys have any other suggestions? > >>> > >>> More of a comment than a suggestion. Given the volume of activity on > the > >>> notifications@ list, the activity on dev@ seems rather low. I'd expect > >>> to see more discussion, more commentary, more planning given the > >>> activity levels. It is possible that this discussion, commentary and > >>> planning just isn't happening but I do find myself wondering if it is > >>> happening off-list. If that is the case, it *really* needs to start > >>> moving on to dev@ list. > >>> > >>> Cheers, > >>> > >>> Mark > >> > >> > > > >
