Re: mailing lists and fragmented communication
On 01/21/2013 11:43 AM, Robbie Gemmell wrote: I don't think that list being separate is the main source of most of the confusion with proton. I agree and was not suggesting that it was. I do however think that had past conversations on both the proton and dev lists been more visible then the community as a whole would have a better view of what was happening and any questions would get asked earlier forcing them to be dealt with earlier. What prompted this thread was the observation that communication was more fragmented than in my view it needed to be, not that this was the cause or solution to any specific point or issue. That is actually something I have felt for a while and not at all specifically with regard to proton. Recent email threads somehow just pushed me from thinking about it to voicing my thoughts out loud. People have asked roughly the same basic questions about proton on users@ and proton@ at roughly the same time, which did indeed mean certain discussion with answers might have only gone to one of the lists at a time, but the key point for me was that they had to ask those basic questions on either list in the first place. We are talking about improving communication, and for me the main problem is often that information isn't being written down or sent to any of the lists until someone asks a question requiring it. That question typically gets met with a [large] email explaining the answer, but much of the time it should be possible for the response to just be a link to somewhere the answer is already written down in general, e.g the website, with perhaps some context-specific additions. Some website update stats would probably entertaining right about now for example. I think the website is indeed a problem area for the project. It does tend to get stale and has never been particularly comprehensive. I think the addition of proton (and indeed the move to AMQP 1.0) is a significant enough change that the overall structure needs some thought. [...] I think users@ and dev@ should be left as is, and that we potentially just adjust how we use them slightly. That is fine with me. I'm really just hoping to nudge more of the conversation emails onto the user list for wider visibility as I think that will be generally beneficial (while not being a panacea for any specific issue or indeed for the need for better communication in general).
Re: mailing lists and fragmented communication
On 01/21/2013 01:14 PM, Gordon Sim wrote: On 01/21/2013 11:43 AM, Robbie Gemmell wrote: I think users@ and dev@ should be left as is, and that we potentially just adjust how we use them slightly. That is fine with me. I'm really just hoping to nudge more of the conversation emails onto the user list for wider visibility as I think that will be generally beneficial (while not being a panacea for any specific issue or indeed for the need for better communication in general). From the website: The user's list is for discussions that relate to use or questions on Qpid. If you have questions about how a feature works, suggestions on additional requirements, or general questions about Qpid please use this list. and: The developer's list is for discussions that relate to the on going development of Qpid. If you have questions about how a feature is being developed, suggestions on how to implement a new feature, or requests for a new feature this is the list to use. So, I guess being more specific, I'm saying that I think suggestions on how to implement a new feature or questions (and discussions) on new features being developed would actually be better directed to the user list. I certainly don't want to spam user with unwanted emails, but the volume historically has not been that high and I suspect that doing so will give users a greater sense of awareness of what's coming down the line (yes, we should be better at communicating that through more formal roadmaps etc, but this would at least alleviate our current failings) and would result in wider input into design questions.
Re: mailing lists and fragmented communication
On 21 January 2013 12:43, Robbie Gemmell robbie.gemm...@gmail.com wrote: I'm happy enough with the idea of collapsing proton@ given that Protons scope is in some ways wider than when it started out (where the very specific protocol library made a good case for a separate list), but I don't think that list being separate is the main source of most of the confusion with proton. People have asked roughly the same basic questions about proton on users@ and proton@ at roughly the same time, which did indeed mean certain discussion with answers might have only gone to one of the lists at a time, but the key point for me was that they had to ask those basic questions on either list in the first place. +1 We are talking about improving communication, and for me the main problem is often that information isn't being written down or sent to any of the lists until someone asks a question requiring it. That question typically gets met with a [large] email explaining the answer, but much of the time it should be possible for the response to just be a link to somewhere the answer is already written down in general, e.g the website, with perhaps some context-specific additions. Some website update stats would probably entertaining right about now for example. Completely agreed (and hands up to not personally having updated the website in ages). I think users@ and dev@ should be left as is, and that we potentially just adjust how we use them slightly. These lists have existed for several years, and its the structure almost every Apache project works away just fine with; I don't think we are all that special in this regard. I also don't think we should subscribe everyone to a bunch of traffic they didn't sign up for. That said, this doesn't mean developers actually need to post discussion mails to dev@, the users@ list is always there and I know Gordon at least often posts only to that if it is a user related discussion, and I think that approach works well enough if others were to use it. The dev@ list can continue at least to hold things like the JIRA traffic (I could see ReviewBoard postings going to either list), even if general discussion moves to the users@ list. Personally I'd have JIRAs and ReviewBoards on dev and make sure everything else was on users. However I agree with your main point that it's not the multitude of mailing lists that is necessarily the issue... it's the fact that information isn't available *anywhere* :-) Summarising, I agree we need to be better at communicating, I think a bit of mailing list adjustment would be a good thing where proton@ could go and dev@ should stay in some guise, but that there are other problems with our communication that reducing the number of mailing lists potentially does little to solve. Agreed, Rob Robbie On 18 January 2013 17:21, Gordon Sim g...@redhat.com wrote: I believe that we have too many mailing lists and that we are missing out on valuable collaboration and transparency as a result. Too often in the past topics have been discussed on the dev list without reflecting any of the discussion back to the user list, keeping a large part of the community in the dark. Now that we have a distinct list for proton there is the possibility of yet more fragmentation. I honestly believe that we would be better off with just one list for discussions. I think there will increasingly be issues that cross-cut different components or that would benefit from wider participation. Not all topics will be of interest to all subscribers, but that is always going to be the case. It doesn't seem to me like any of the lists are so high in volume that this would cause significant problems. More rigorous use of subject could help people filter if needed. (JIRA and commit notices I think do warrant their own lists allowing a lot of the 'noise' to be avoided if so desired). Any other thoughts on this? Does anyone have fears of being deluged with unwanted emails? --**--**- To unsubscribe, e-mail: users-unsubscribe@qpid.apache.**org users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: mailing lists and fragmented communication
On 21 January 2013 13:14, Gordon Sim gordon.r@gmail.com wrote: On 01/21/2013 11:43 AM, Robbie Gemmell wrote: I don't think that list being separate is the main source of most of the confusion with proton. I agree and was not suggesting that it was. Sorry, I didnt really mean to imply you were suggesting that it was (or that it was part of your motivation), I just felt that it had been suggested. I was just being lazy and replying to / giving my thoughts on the entire thread in one email. I do however think that had past conversations on both the proton and dev lists been more visible then the community as a whole would have a better view of what was happening and any questions would get asked earlier forcing them to be dealt with earlier. Agreed
summary/conclusion (was Re: mailing lists and fragmented communication)
I'm going to suggest that we leave all the lists in place for now, and leave the choice of list to individual discretion. For my part however I will be focusing on the user list, which I see as a community wide list for anyone with an interest at AMQP related software at Apache. I would encourage people to only use other lists if they are convinced this is too wide an audience for their thread.
Re: mailing lists and fragmented communication
It's really about architecture and audience and how they interact. The architecture we are currently developing is closely modelled on the existing architecture of the internet. At the lowest layer the TCP stack provides a very general purpose protocol to a very wide range of applications. This is directly the role the protocol engine plays for AMQP. Slightly above that in the software stack the socket API makes it easy (relatively speaking) for your application to speak TCP. Again this is identical to the role that the Messenger API serves. Neither the socket API nor Messenger provide you direct control over every aspect of the protocol details, but they do make it easy to interface to the basic functionality of the respective protocols and they provide you indirect access (via intermediaries) to many more advanced capabilities of the protocol. At the highest layer applications build on top of the protocol. In the case of TCP there are many thousands of applications including very important ones like HTTP, SMTP, etc. For AMQP, we currently have three examples at apache (the cpp/java brokers, and activemq), however I believe there are potentially many many other applications that could build on top of AMQP, perhaps even as many as currently exist on TCP. From this perspective, I would assert that both messenger and the protocol engine have potentially very cross-cutting and broad audiences, whereas the brokers (relatively speaking) have inherently narrower and more domain specific audiences. While I can sympathize with the idea that a single broadcast communication channel might make it easier to explain this picture in the short term, I am deeply concerned that it will lead to distortion of this picture in the longer term as architecture tends to follow audience. The users of a piece of software inherently shape its direction, and forcing two pieces of software that need to be quite independent to have a single user group is going to influence and shape that architecture in a way that is contrary to them being independent in the first place. I think this is especially concerning because the dev and users list are already largely established as the cpp/java broker lists. So to answer your question, I don't actually think the arrangement of mailing lists will make all that much difference in the short term, that is something we need to proactively work on through other means, however I do think it can have a significant influence in the long term. It is my belief that if AMQP is successful the architectural layer represented by the protocol engine + messenger, and the various applications that use it (qpid-cpp, qpid-ava, activemq, and more) will ultimately be strongly reflected in their own distinct communities and it may well be as strange and alien to think of merging the communities/lists as it would be to combine the TCP stack/socket API into a single project with the apache web server. Already it's hard to imagine how the details of implementing ssl support in proton and the details of implementing a transactional persistent message store will significantly benefit from cross communication. All that said, my primary concern is to promote a good understanding and foster development of the architecture outlined above, and this requires good communication beyond just the people who are on any of our mailing lists. If we can't explain proton to users of other qpid components, we certainly can't explain it well to the rest of the world. So if the above picture is well understood and there is still overwhelming consensus that merging lists will help achieve this goal then I won't stand in the way. I don't claim to know that we can't evolve to where we need to be through that path, merely that it worries me in some significant ways and that qpid mailing list communication in general is a very small subset of our overall communication problems, so any action (or inaction) we take with the lists should not make us feel better about having actually done something to solve the problem. --Rafael On Fri, Jan 18, 2013 at 4:15 PM, Ken Giusti kgiu...@redhat.com wrote: Hi Rafi, You raise some good points, but I don't understand how keeping a separate proton list makes it easier to provide a coherent view of the qpid project, especially to newcomers. As you point out: The project goals/identity issue in my mind has very little to do with the lists and more to do with the fact that many people think of qpid == broker, qpid cpp == cpp broker, and qpid java == java broker. While this understanding may have been more or less true at one point, it is now and going forward a misconception, yet we have done nothing to educate our users about this. Agreed, and to that point, I think it would be a very bad precedent to structure the mailing lists into component silos. Wouldn't creating a separate mailing list for, say qpid-cpp-bro...@qpid.apache.org, send exactly the wrong message?
Re: mailing lists and fragmented communication
On Mon, Jan 21, 2013 at 1:42 PM, Gordon Sim g...@redhat.com wrote: On 01/21/2013 05:22 PM, Rafael Schloming wrote: The users of a piece of software inherently shape its direction, and forcing two pieces of software that need to be quite independent to have a single user group is going to influence and shape that architecture in a way that is contrary to them being independent in the first place. Having a single communication channel for a community is not the same as forcing independent pieces of software to have a single user group. No one is 'forcing' anyone into anything. I don't believe having more conversations in the wider community need have any negative impact on the architecture of independent components. I think this is especially concerning because the dev and users list are already largely established as the cpp/java broker lists. I think the lists are as much about the clients (and indeed management mechanisms) as the brokers. I see them as being places where all the components have been discussed, in combination with each other or in conjunction with software outside the project (RabbitMQ, Mule etc etc). The conversations evolve as the components evolve. Ultimately people talk about what they are interested in and what they are using. None of our lists are particularly high volume at this point, so I am of the opinion that there is more benefit to sharing a channel of communication than there is from segmenting it. [...] It is my belief that if AMQP is successful the architectural layer represented by the protocol engine + messenger, and the various applications that use it (qpid-cpp, qpid-ava, activemq, and more) will ultimately be strongly reflected in their own distinct communities and it may well be as strange and alien to think of merging the communities/lists as it would be to combine the TCP stack/socket API into a single project with the apache web server. Time will tell of course, but I myself take a different view. I think the analogy is somewhat flawed. I think AMQP will have a community of interest around it, a community that is specifically driven by the vision of interoperability, of composing systems from many different parts. Not all members of that community will be interested in the exactly the same set of components of course, but I think there will be a lot more common interests than your analogy would suggest. I think there will also be general issues that are relevant to different components (e.g. global addressing). Having an AMQP focused community at Apache and having that community discuss various different components with different architectural relationships seems entirely natural to me. Calling it an analogy is not really being fair. Getting closer to the level of generality I've described has been one of if not the primary design goal behind AMQP 1.0 since it's inception, and the exact parallel I've described has motivated many of its fundamental design choices. You can certainly argue that the design is flawed and it is impossible to implement the architecture in such a decoupled manner, however it's not realistic to simply discount it as a flawed analogy. [...] Already it's hard to imagine how the details of implementing ssl support in proton and the details of implementing a transactional persistent message store will significantly benefit from cross communication. In my view that entirely misses the point. Those topics themselves may seem quite distinct, but there are many people who would be interested in both of those topics. There are also likely some people who might be interested in knowing a bit about them and/or contributing to discussions around them even if they are at present primarily focused on some other component entirely. Clearly users of proton's messenger API may be interested in communicating with a persistent transactional store. Users of other APIs might be interested in how the messenger API differs in that use case with whatever API they use. Implementers of such a store may be interested in proton's engine API (as well as some other broker/brokers). So even with these two distinct topics it seems to me (at the risk of repeating myself to the point you all stop listening and filter my emails to /dev/null!) that there are benefits to sharing a communication channel and at present no real concerns about excessive traffic (at least none so far expressed). I don't think I've missed your point. I agree 100% with you that we need more communication about architecture and how components fit together and that this communication needs to reach a lot of people. Where I disagree with you is that altering the mailing lists will achieve a significant measure of that goal. This communication really needs to be captured in a more permanent form that can be sent (ideally via a small easy to remember URL) to lots of mailing lists, even (perhaps especially) ones
Re: mailing lists and fragmented communication
On 01/21/2013 07:39 PM, Rafael Schloming wrote: Calling it an analogy is not really being fair. Getting closer to the level of generality I've described has been one of if not the primary design goal behind AMQP 1.0 since it's inception, and the exact parallel I've described has motivated many of its fundamental design choices. You can certainly argue that the design is flawed and it is impossible to implement the architecture in such a decoupled manner, however it's not realistic to simply discount it as a flawed analogy. I'm not arguing that the design is flawed. I'm arguing that comparing the relationship of the TCP stack to the Apache Web server as being the same as that of Proton to a specific broker implementation and drawing from that the conclusion that the communities around them are thus necessarily as distinct is unconvincing to me. [...] I agree 100% with you that we need more communication about architecture and how components fit together and that this communication needs to reach a lot of people. Where I disagree with you is that altering the mailing lists will achieve a significant measure of that goal. I don't believe I ever argued that it would. This communication really needs to be captured in a more permanent form that can be sent (ideally via a small easy to remember URL) to lots of mailing lists, even (perhaps especially) ones outside of qpid. Sounds great! Even when that exists though, I still believe a single list on which the community can discuss diverse AMQP and Qpid related topics is a good thing.
Re: mailing lists and fragmented communication
On Mon, Jan 21, 2013 at 3:10 PM, Gordon Sim g...@redhat.com wrote: On 01/21/2013 07:39 PM, Rafael Schloming wrote: Calling it an analogy is not really being fair. Getting closer to the level of generality I've described has been one of if not the primary design goal behind AMQP 1.0 since it's inception, and the exact parallel I've described has motivated many of its fundamental design choices. You can certainly argue that the design is flawed and it is impossible to implement the architecture in such a decoupled manner, however it's not realistic to simply discount it as a flawed analogy. I'm not arguing that the design is flawed. I'm arguing that comparing the relationship of the TCP stack to the Apache Web server as being the same as that of Proton to a specific broker implementation and drawing from that the conclusion that the communities around them are thus necessarily as distinct is unconvincing to me. I certainly wasn't intending to draw such a conclusion, and I apologize for any sloppy wording that may have implied this. I'm merely stating my own beliefs and conjectures about the future. I've conceded that you can do what you like with the lists and I won't stand in the way, however I can't make myself believe that it is the right choice, and if only for my own cathartic benefit I feel the need to document the minority view. Ultimately the dissent over this issue is more damaging than simply moving forward and making progress. I've pushed it as much as I have in the past because I do have very strong beliefs surrounding it and I'm sorry if trying to explain my perspective has wasted more time. --Rafael
mailing lists and fragmented communication
I believe that we have too many mailing lists and that we are missing out on valuable collaboration and transparency as a result. Too often in the past topics have been discussed on the dev list without reflecting any of the discussion back to the user list, keeping a large part of the community in the dark. Now that we have a distinct list for proton there is the possibility of yet more fragmentation. I honestly believe that we would be better off with just one list for discussions. I think there will increasingly be issues that cross-cut different components or that would benefit from wider participation. Not all topics will be of interest to all subscribers, but that is always going to be the case. It doesn't seem to me like any of the lists are so high in volume that this would cause significant problems. More rigorous use of subject could help people filter if needed. (JIRA and commit notices I think do warrant their own lists allowing a lot of the 'noise' to be avoided if so desired). Any other thoughts on this? Does anyone have fears of being deluged with unwanted emails?
Re: mailing lists and fragmented communication
On 01/18/2013 05:33 PM, Ted Ross wrote: We either exclude people by sending to one list or, like this email, we include all lists and everybody gets three copies. Its not the duplicate copies that are the biggest issue with cross posting in my view, its the tendency for the thread to get fragmented when someone replies only to one of the lists.
Re: mailing lists and fragmented communication
On Jan 18, 2013, at 12:51 PM, Gordon Sim g...@redhat.com wrote: On 01/18/2013 05:33 PM, Ted Ross wrote: We either exclude people by sending to one list or, like this email, we include all lists and everybody gets three copies. Its not the duplicate copies that are the biggest issue with cross posting in my view, its the tendency for the thread to get fragmented when someone replies only to one of the lists. +1 - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: mailing lists and fragmented communication
I'm in favor of combining them all into one. If not that, then at least collapse the proton list. The level of traffic on that list isn't unreasonable, and, frankly, keeping it separate probably leads to some of the confusion we're seeing over the goals of this project. -K - Original Message - I believe that we have too many mailing lists and that we are missing out on valuable collaboration and transparency as a result. Too often in the past topics have been discussed on the dev list without reflecting any of the discussion back to the user list, keeping a large part of the community in the dark. Now that we have a distinct list for proton there is the possibility of yet more fragmentation. I honestly believe that we would be better off with just one list for discussions. I think there will increasingly be issues that cross-cut different components or that would benefit from wider participation. Not all topics will be of interest to all subscribers, but that is always going to be the case. It doesn't seem to me like any of the lists are so high in volume that this would cause significant problems. More rigorous use of subject could help people filter if needed. (JIRA and commit notices I think do warrant their own lists allowing a lot of the 'noise' to be avoided if so desired). Any other thoughts on this? Does anyone have fears of being deluged with unwanted emails? - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
RE: mailing lists and fragmented communication
I agree that the qpid and proton users should be on the same list. Also, it's useful for much of the development info to be open to the users list. My only concern for a second list is for things that committers may need to talk about but which the larger user community doesn't care about. For example, who broke the build or questions/issues about the release process, etc. -Steve -Original Message- From: Gordon Sim [mailto:g...@redhat.com] Sent: Friday, January 18, 2013 12:21 PM To: us...@qpid.apache.org; proton@qpid.apache.org; d...@qpid.apache.org Subject: mailing lists and fragmented communication I believe that we have too many mailing lists and that we are missing out on valuable collaboration and transparency as a result. Too often in the past topics have been discussed on the dev list without reflecting any of the discussion back to the user list, keeping a large part of the community in the dark. Now that we have a distinct list for proton there is the possibility of yet more fragmentation. I honestly believe that we would be better off with just one list for discussions. I think there will increasingly be issues that cross-cut different components or that would benefit from wider participation. Not all topics will be of interest to all subscribers, but that is always going to be the case. It doesn't seem to me like any of the lists are so high in volume that this would cause significant problems. More rigorous use of subject could help people filter if needed. (JIRA and commit notices I think do warrant their own lists allowing a lot of the 'noise' to be avoided if so desired). Any other thoughts on this? Does anyone have fears of being deluged with unwanted emails? - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: mailing lists and fragmented communication
On Fri, Jan 18, 2013 at 05:21:21PM +, Gordon Sim wrote: snip Any other thoughts on this? Does anyone have fears of being deluged with unwanted emails? I think you're mostly right on this. In thinking about the split of lists, a project like Qpid doesn't really have a separate of users and developers; i.e., if you're a user of Qpid you're also a developer, not of Qpid but at least of some application that's consuming the Qpid APIs. Given that, there's less value in dividing up conversations but, instead, keeping them in a single mailing list -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgptc4uE61zdY.pgp Description: PGP signature
Re: mailing lists and fragmented communication
On Fri, Jan 18, 2013 at 02:19:01PM -0500, Darryl L. Pierce wrote: On Fri, Jan 18, 2013 at 05:21:21PM +, Gordon Sim wrote: snip Any other thoughts on this? Does anyone have fears of being deluged with unwanted emails? I think you're mostly right on this. In thinking about the split of lists, a project like Qpid doesn't really have a separate of users and developers; i.e., if you're a user of Qpid you're also a developer, not of Qpid but at least of some application that's consuming the Qpid APIs. Given that, there's less value in dividing up conversations but, instead, keeping them in a single mailing list Sorry, I also meant to say that Qpid and Proton as well should be collapsed into a single list, not just dev and user. -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/ pgp70fSmU0TZs.pgp Description: PGP signature
Re: mailing lists and fragmented communication
On Jan 18, 2013, at 2:19 PM, Darryl L. Pierce dpie...@redhat.com wrote: On Fri, Jan 18, 2013 at 05:21:21PM +, Gordon Sim wrote: snip Any other thoughts on this? Does anyone have fears of being deluged with unwanted emails? I think you're mostly right on this. In thinking about the split of lists, a project like Qpid doesn't really have a separate of users and developers; i.e., if you're a user of Qpid you're also a developer, not of Qpid but at least of some application that's consuming the Qpid APIs. +1 Good point, never thought of it that way but makes a lot of sense to me. Given that, there's less value in dividing up conversations but, instead, keeping them in a single mailing list -- Darryl L. Pierce, Sr. Software Engineer @ Red Hat, Inc. Delivering value year after year. Red Hat ranks #1 in value among software vendors. http://www.redhat.com/promo/vendor/
Re: mailing lists and fragmented communication
Hi Rafi, You raise some good points, but I don't understand how keeping a separate proton list makes it easier to provide a coherent view of the qpid project, especially to newcomers. As you point out: The project goals/identity issue in my mind has very little to do with the lists and more to do with the fact that many people think of qpid == broker, qpid cpp == cpp broker, and qpid java == java broker. While this understanding may have been more or less true at one point, it is now and going forward a misconception, yet we have done nothing to educate our users about this. Agreed, and to that point, I think it would be a very bad precedent to structure the mailing lists into component silos. Wouldn't creating a separate mailing list for, say qpid-cpp-bro...@qpid.apache.org, send exactly the wrong message? Yet proton@qpid.apache.org somehow doesn't? If we really want people to think of QPID as being more than just a cpp broker/java broker/etc, then we should start by revising the very first paragraph of our homepage: Introduction Apache Qpid™ is a cross-platform Enterprise Messaging system which implements the Advanced Message Queuing Protocol (AMQP), providing message brokers written in C++ and Java, along with clients for C++, Java JMS, .Net, Python, and Ruby. -K - Original Message - I think you raise a good point about the goals of the project being confused, but don't think the cause here is mailing lists. As we've seen, recent threads have asked about qpid vs proton, and to a lot of us this is an odd thing to ask about because we think of proton as part of qpid. However we who are close to the project also think of qpid as something that is larger than just a broker. The project goals/identity issue in my mind has very little to do with the lists and more to do with the fact that many people think of qpid == broker, qpid cpp == cpp broker, and qpid java == java broker. While this understanding may have been more or less true at one point, it is now and going forward a misconception, yet we have done nothing to educate our users about this. I think this is really at the core of the identity issues, and if anything a separate proton list has helped raise these issues to the surface, because at least it is clear that proton is something that is self contained and distinct from the cpp broker and the java broker. I would hate to lose that distinction and have it all turn into one big jumbled muddle. I think rearranging the lists is not a substitute for rearranging the project and actively communicating about its structure. I may be in the minority with my -1, but I think there is actually a lot more work that needs to be done surrounding project structure, identity, documentation, communication, etc, and simply rearranging lists without doing the rest of that work is IMHO jumping the gun. --Rafael On Fri, Jan 18, 2013 at 1:14 PM, Ken Giusti kgiu...@redhat.com wrote: I'm in favor of combining them all into one. If not that, then at least collapse the proton list. The level of traffic on that list isn't unreasonable, and, frankly, keeping it separate probably leads to some of the confusion we're seeing over the goals of this project. -K - Original Message - I believe that we have too many mailing lists and that we are missing out on valuable collaboration and transparency as a result. Too often in the past topics have been discussed on the dev list without reflecting any of the discussion back to the user list, keeping a large part of the community in the dark. Now that we have a distinct list for proton there is the possibility of yet more fragmentation. I honestly believe that we would be better off with just one list for discussions. I think there will increasingly be issues that cross-cut different components or that would benefit from wider participation. Not all topics will be of interest to all subscribers, but that is always going to be the case. It doesn't seem to me like any of the lists are so high in volume that this would cause significant problems. More rigorous use of subject could help people filter if needed. (JIRA and commit notices I think do warrant their own lists allowing a lot of the 'noise' to be avoided if so desired). Any other thoughts on this? Does anyone have fears of being deluged with unwanted emails? - To unsubscribe, e-mail: users-unsubscr...@qpid.apache.org For additional commands, e-mail: users-h...@qpid.apache.org
Re: mailing lists and fragmented communication
On 01/18/2013 08:23 PM, Rafael Schloming wrote: I think rearranging the lists is not a substitute for rearranging the project and actively communicating about its structure. I quite agree. My suggestion to consolidate discussions to one list is not an attempt to imply anything about structure, but simply a way of improving the flow of information. I may be in the minority with my -1, but I think there is actually a lot more work that needs to be done surrounding project structure, identity, documentation, communication, etc, and simply rearranging lists without doing the rest of that work is IMHO jumping the gun. I don't think having a separate mailing list is the right way to ensure the proton toolkit remains distinct and self contained. That is done much more effectively through svn structure, build release processes and as you very rightly point out, better documentation and communication. I believe communication will be simpler and more effective with one list. I believe a less fragmented discussion will more quickly lead to question being raised and answered and consensus and common understanding growing.
RE: mailing lists and fragmented communication
Sounds good to me. -Original Message- From: Gordon Sim [mailto:g...@redhat.com] Sent: Friday, January 18, 2013 5:12 PM To: us...@qpid.apache.org; proton@qpid.apache.org; d...@qpid.apache.org Subject: Re: mailing lists and fragmented communication On 01/18/2013 06:55 PM, Steve Huston wrote: I agree that the qpid and proton users should be on the same list. Also, it's useful for much of the development info to be open to the users list. My only concern for a second list is for things that committers may need to talk about but which the larger user community doesn't care about. For example, who broke the build or questions/issues about the release process, etc. I sympathise with the concern, and certainly don't want to impose irrelevant emails on people. In practice I think the volume of messages is low and in my view at least, unlikely to be a serious nuisance. I do think that having wider awareness of and involvement in the release process would be a good thing for all of us. Sometimes even the 'who broke the build' type mails can convey what is coming down the road and allow users to comment or get involved earlier in the process. - To unsubscribe, e-mail: dev-unsubscr...@qpid.apache.org For additional commands, e-mail: dev-h...@qpid.apache.org
