Re: Mailinglists - a tool from the 90s?
Hello, Guys, don't get me wrong, but you're sounding like a bunch of old man talking about the good old days, where you did everything on the command line. ;-) I'm 29 and before Apache, I hadn't heard about mailing lists. It always felt clumsy to me. I know github and twitter. That's just the stuff my generation uses. I understand the requirements Phil brought up. But I don't think that mailing lists are the golden way to fulfill those requirements. And when people stop contributing because they don't like the tools we use, then we have a problem. No matter how fancy one can configure thunderbird rules... (BTW I'm using gmail for Apache Mails and it works pretty well. It's the only way I can have the same filters on all of my devices...) I like Benson's idea of improving the searching facilities. But IMHO this is addressing only part of the story. As I said before, what I love about github is, that everything is integrated with the code. ASF is about the code. If there where no code, there wouldn't be any discussions. I don't think it would be to hard for infra to host a gitlab instance [1] or even get a github enterprise plan [2]. Everything would run on ASF infra, code would be integrated. I would be happy. We could set it up so that it sends an email to a mailing list for every code change/comment/ticket. Win Win situation ;-) Best regards, Benedikt [1] https://about.gitlab.com/ [2] https://enterprise.github.com/ 2015-01-19 6:41 GMT+01:00 Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com: I'll certainly admit that I'm a traditionalist. But I hope that I can be credited with trying other things when they come along. Unfortunately, there is no other format of communications that is standards based and thus has all the necessary tools for being productive. If there were I'd be happy to use it. My car has a cassette player, but I haven't owned a cassette for something like 25 years. I do think that something better than email will emerge one day, but it isn't around today. Ross Sent from my Windows Phone From: Dennis E. Hamiltonmailto:dennis.hamil...@acm.org Sent: 1/18/2015 9:20 AM To: dev@community.apache.orgmailto:dev@community.apache.org Subject: RE: Mailinglists - a tool from the 90s? I think Ross's consideration also applies to the many folks who cling to technology of the 70s (i.e., the Internet versions of News Readers) to access and contribute to ASF mailing lists. - Dennis -Original Message- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Sunday, January 18, 2015 07:29 To: dev@community.apache.org Subject: RE: Mailinglists - a tool from the 90s? For me any alternative would still have to push everything into my inbox where I can use a my preferred tools, each developed and matured over many years, to help me process the volume of communications I need (filters, archives, calendars etc.) Ross Sent from my Windows Phone From: Benedikt Rittermailto:brit...@apache.org Sent: 1/18/2015 4:35 AM To: dev@community.apache.orgmailto:dev@community.apache.org Subject: Mailinglists - a tool from the 90s? Hi all, over at the Apache Commons Project, we have a long discussion about our mailing lists. Are they to noisy? Should they be splitted up into sublists? Should individual components go TLP? IMHO Ben McCann summed up the core problem pretty well [1]. Mailing lists are simply a outdated tool from the 90s. They can not compete with tools like github/gitlab that integrate the code with the possibility to do code reviews, disucssions and bugtracking. Now I'm curious: Does anybody here really like the use of mailing lists? Or do we all simply go through the struggle of setting up filters etc. just because this is the way it has always been? Regards, Benedikt [1] http://markmail.org/message/iizay3mmf2msvaf2 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
RE: Mailinglists - a tool from the 90s?
I'll certainly admit that I'm a traditionalist. But I hope that I can be credited with trying other things when they come along. Unfortunately, there is no other format of communications that is standards based and thus has all the necessary tools for being productive. If there were I'd be happy to use it. My car has a cassette player, but I haven't owned a cassette for something like 25 years. I do think that something better than email will emerge one day, but it isn't around today. Ross Sent from my Windows Phone From: Dennis E. Hamiltonmailto:dennis.hamil...@acm.org Sent: 1/18/2015 9:20 AM To: dev@community.apache.orgmailto:dev@community.apache.org Subject: RE: Mailinglists - a tool from the 90s? I think Ross's consideration also applies to the many folks who cling to technology of the 70s (i.e., the Internet versions of News Readers) to access and contribute to ASF mailing lists. - Dennis -Original Message- From: Ross Gardler (MS OPEN TECH) [mailto:ross.gard...@microsoft.com] Sent: Sunday, January 18, 2015 07:29 To: dev@community.apache.org Subject: RE: Mailinglists - a tool from the 90s? For me any alternative would still have to push everything into my inbox where I can use a my preferred tools, each developed and matured over many years, to help me process the volume of communications I need (filters, archives, calendars etc.) Ross Sent from my Windows Phone From: Benedikt Rittermailto:brit...@apache.org Sent: 1/18/2015 4:35 AM To: dev@community.apache.orgmailto:dev@community.apache.org Subject: Mailinglists - a tool from the 90s? Hi all, over at the Apache Commons Project, we have a long discussion about our mailing lists. Are they to noisy? Should they be splitted up into sublists? Should individual components go TLP? IMHO Ben McCann summed up the core problem pretty well [1]. Mailing lists are simply a outdated tool from the 90s. They can not compete with tools like github/gitlab that integrate the code with the possibility to do code reviews, disucssions and bugtracking. Now I'm curious: Does anybody here really like the use of mailing lists? Or do we all simply go through the struggle of setting up filters etc. just because this is the way it has always been? Regards, Benedikt [1] http://markmail.org/message/iizay3mmf2msvaf2 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: Mailinglists - a tool from the 90s?
I prefer the mailing list because it pushes new concepts to me. Git and such requires that I work harder to get the information. Most of the Apache mailing lists have a high signal to noise ratio. And even the signals I am not interested in don't take that long to dispose of. Claude On Sun, Jan 18, 2015 at 12:34 PM, Benedikt Ritter brit...@apache.org wrote: Hi all, over at the Apache Commons Project, we have a long discussion about our mailing lists. Are they to noisy? Should they be splitted up into sublists? Should individual components go TLP? IMHO Ben McCann summed up the core problem pretty well [1]. Mailing lists are simply a outdated tool from the 90s. They can not compete with tools like github/gitlab that integrate the code with the possibility to do code reviews, disucssions and bugtracking. Now I'm curious: Does anybody here really like the use of mailing lists? Or do we all simply go through the struggle of setting up filters etc. just because this is the way it has always been? Regards, Benedikt [1] http://markmail.org/message/iizay3mmf2msvaf2 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
Mailing lists, sites, ...
Hi Apache . Every so often we get the question come up: does Apache infra allow/support . The answer is sometimes not yet and related to the fact that there are 100s of projects that require uniformity at Apache, and it would be chaos of every new project was allowed a new infrastructure. Idea: Now that project infrastructure is easier using things like github and static sites or google groups forums etc Maybe the ASF could loosely agree to support some types of alternative project tooling, as long all project conversations and decisions and artifacts were centrally archived at Apache?This can easily be done by simply adding an Apache email address to a monitor a particular forum , or github issues notifications or whatever. Benefits of looser grip on community infrastructure: The main benefit of Apache in a post github era is not the storage and mail servers - it's the centralized archiving, community process, and transparent workflow. And those things can be implemented with any technology. So, my general thought is : Apache still can enforce its core principals while loosening some of the more granular rules around infrastructure . Maybe the time is now (or maybe not) to start allowing projects to branch out their tooling ... While still supporting the tried and true mechanisms and not pressuring infra every time someone wants to use some new email alternative or site hosting solution. In any case looking forward to feedback on this from some Apache veterans .
RE: Mailing lists, sites, ...
There are many reasons why the ASF requires projects to use its own servers for some items. For example, we couldn't use GitHub until we had built a system that would provide adequate traceability of contributions. Failure to do that would have meant it was no longer possible to provide the legal umbrella necessary to protect developers and reassure users. Such work takes resources. Add to that the fact there is no guarantee that an external service will still be available, in an appropriate form, tomorrow. There is therefore a risk that projects will be damaged by decisions outside of our control. Replacing such lost services requires resources. Finally, one of the advantages of the ASF is that once you know the core principles of how one project works, you know them for all projects. Our response to these issues is to require projects to use ASF provided services for essential items. What has been unclear is what are these essential items and what can our projects expect from the ASF in the non-essential areas. David Nalley and I, as part of our budget planning, are working on identifying what is considered core and what is not. This will help address the confusion and therefore make it easier for project communities to decide whether they can use external services. What we will not be doing is relaxing any of our rules designed to protect the independence and legal governance of our projects. Sent from my Windows Phone From: Jay Vyasmailto:jayunit100.apa...@gmail.com Sent: 1/18/2015 7:37 AM To: dev@community.apache.orgmailto:dev@community.apache.org Subject: Mailing lists, sites, ... Hi Apache . Every so often we get the question come up: does Apache infra allow/support . The answer is sometimes not yet and related to the fact that there are 100s of projects that require uniformity at Apache, and it would be chaos of every new project was allowed a new infrastructure. Idea: Now that project infrastructure is easier using things like github and static sites or google groups forums etc Maybe the ASF could loosely agree to support some types of alternative project tooling, as long all project conversations and decisions and artifacts were centrally archived at Apache?This can easily be done by simply adding an Apache email address to a monitor a particular forum , or github issues notifications or whatever. Benefits of looser grip on community infrastructure: The main benefit of Apache in a post github era is not the storage and mail servers - it's the centralized archiving, community process, and transparent workflow. And those things can be implemented with any technology. So, my general thought is : Apache still can enforce its core principals while loosening some of the more granular rules around infrastructure . Maybe the time is now (or maybe not) to start allowing projects to branch out their tooling ... While still supporting the tried and true mechanisms and not pressuring infra every time someone wants to use some new email alternative or site hosting solution. In any case looking forward to feedback on this from some Apache veterans .
Re: Mailinglists - a tool from the 90s?
Perhaps there is an opportunity here for a new Apache project that can meet the requirements outlined above. But then that might just be a me too implementation of several new mail reading/processing tools from the big companies. On Sun, Jan 18, 2015 at 1:21 PM, jan i j...@apache.org wrote: On 18 January 2015 at 14:15, Benson Margulies bimargul...@gmail.com wrote: The Apache Software Foundation has a requirement of open, public, decision-making. The short-hand implication of those requirements is that 'discussions that lead to decisions are made on mailing lists.' Closely related is the requirement that important functions take place on ASF infrastructure. I emphasize 'short-hand'. If a PMC wants to contemplate some alternative technology that satisfies the underlying requirement, the PMC can experiment with that; for anything radical, it's probably best to talk to the board early and often -- who might reflect you to, say, infra@. It will not lead to open decision-making if some project use different medias than other, it will complicate searching quite a lot. If (and it is a big if) ASF should change the mailing list policy it should be done in a uniform way for all projects. rgds jan i Many projects use other things and arrange for them to send email to the list as the official record; such as JIRA. Personally, I think it's a question whether a mailing list consisting only of a constant torrent of notifications from JIRA, or some code review tool, really meets up with the intent of the policy. The argument in favor is that any community member sees all the traffic and can hoist themselves over to the tool to be an equal participant. On Sun, Jan 18, 2015 at 7:53 AM, Claude Warren cla...@xenei.com wrote: I prefer the mailing list because it pushes new concepts to me. Git and such requires that I work harder to get the information. Most of the Apache mailing lists have a high signal to noise ratio. And even the signals I am not interested in don't take that long to dispose of. Claude On Sun, Jan 18, 2015 at 12:34 PM, Benedikt Ritter brit...@apache.org wrote: Hi all, over at the Apache Commons Project, we have a long discussion about our mailing lists. Are they to noisy? Should they be splitted up into sublists? Should individual components go TLP? IMHO Ben McCann summed up the core problem pretty well [1]. Mailing lists are simply a outdated tool from the 90s. They can not compete with tools like github/gitlab that integrate the code with the possibility to do code reviews, disucssions and bugtracking. Now I'm curious: Does anybody here really like the use of mailing lists? Or do we all simply go through the struggle of setting up filters etc. just because this is the way it has always been? Regards, Benedikt [1] http://markmail.org/message/iizay3mmf2msvaf2 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
Mailinglists - a tool from the 90s?
Hi all, over at the Apache Commons Project, we have a long discussion about our mailing lists. Are they to noisy? Should they be splitted up into sublists? Should individual components go TLP? IMHO Ben McCann summed up the core problem pretty well [1]. Mailing lists are simply a outdated tool from the 90s. They can not compete with tools like github/gitlab that integrate the code with the possibility to do code reviews, disucssions and bugtracking. Now I'm curious: Does anybody here really like the use of mailing lists? Or do we all simply go through the struggle of setting up filters etc. just because this is the way it has always been? Regards, Benedikt [1] http://markmail.org/message/iizay3mmf2msvaf2 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: Mailinglists - a tool from the 90s?
The Apache Software Foundation has a requirement of open, public, decision-making. The short-hand implication of those requirements is that 'discussions that lead to decisions are made on mailing lists.' Closely related is the requirement that important functions take place on ASF infrastructure. I emphasize 'short-hand'. If a PMC wants to contemplate some alternative technology that satisfies the underlying requirement, the PMC can experiment with that; for anything radical, it's probably best to talk to the board early and often -- who might reflect you to, say, infra@. Many projects use other things and arrange for them to send email to the list as the official record; such as JIRA. Personally, I think it's a question whether a mailing list consisting only of a constant torrent of notifications from JIRA, or some code review tool, really meets up with the intent of the policy. The argument in favor is that any community member sees all the traffic and can hoist themselves over to the tool to be an equal participant. On Sun, Jan 18, 2015 at 7:53 AM, Claude Warren cla...@xenei.com wrote: I prefer the mailing list because it pushes new concepts to me. Git and such requires that I work harder to get the information. Most of the Apache mailing lists have a high signal to noise ratio. And even the signals I am not interested in don't take that long to dispose of. Claude On Sun, Jan 18, 2015 at 12:34 PM, Benedikt Ritter brit...@apache.org wrote: Hi all, over at the Apache Commons Project, we have a long discussion about our mailing lists. Are they to noisy? Should they be splitted up into sublists? Should individual components go TLP? IMHO Ben McCann summed up the core problem pretty well [1]. Mailing lists are simply a outdated tool from the 90s. They can not compete with tools like github/gitlab that integrate the code with the possibility to do code reviews, disucssions and bugtracking. Now I'm curious: Does anybody here really like the use of mailing lists? Or do we all simply go through the struggle of setting up filters etc. just because this is the way it has always been? Regards, Benedikt [1] http://markmail.org/message/iizay3mmf2msvaf2 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- I like: Like Like - The likeliest place on the web http://like-like.xenei.com LinkedIn: http://www.linkedin.com/in/claudewarren
Re: Mailinglists - a tool from the 90s?
On 18.01.2015 19:23, Phil Steitz wrote: One thing that I agree is a shame is the deterioration of mail clients and archive search tools. Gmail is a disaster. I personally use Thunderbird for all ASF lists. I also use markmail a lot for searching, as it is superior to what we have internally. Hear hear. Google messed up royally with GMail. Thunderbird is the last mail client that even tries to be useful and conformant ... the one before that was mutt. Considering how long e-mail has been around, this is a major disaster. The problem with e-mail is not that it's 90's technology, it's that most people use clients that are apparently designed to be as bad and useless as possible. This trend started with Outlook ... and I'm disgusted that Google followed in Microsoft's steps in this respect. -- Brane
Re: Mailinglists - a tool from the 90s?
On Sun, Jan 18, 2015 at 7:34 AM, Benedikt Ritter brit...@apache.org wrote: [snip] Now I'm curious: Does anybody here really like the use of mailing lists? Or do we all simply go through the struggle of setting up filters etc. just because this is the way it has always been? I absolutely loathe mailing lists: 1. They *feel* like spam (Google often incorrectly identifies ASF mailing list activity as spam). 2. They are difficult to parse (visually) and triage/categorize (subject line conventions help to some degree). 3. They are often full of pages and pages of text, which could be more easily conveyed by a more succinct means, with the best option to provide a link to an external resource (which creates a slight burden on the composer). 4. Long conversations often get forked, and are difficult to follow (esp. in tools like GMail which doesn't thread conversations natively). Even when not forked, they can be difficult to determine whom one is responding to when replies are interspersed. 5. Outages and late-subscribers can get messages at different times, and dealing with backlog is not so easy. 6. The archives are profoundly difficult to navigate and reference (though, that's specific to ASF archives, not necessarily generally true). 7. Filters are useful, but have limited ability to address all the issues. 8. Client-side identity management is a pain, when you have multiple email addresses for different purposes, and the mailing lists expose you to spam. 9. Replying is inefficient and ugly, with different community conventions (top-posting, bottom-posting, inline-posting) on mailing lists. 10. Message sizes when replying is often inefficient. Most people quote the entire previous message, including any previously quoted messages, indenting and wrapping, sending and storing redundant bits which are difficult to read anyway. 11. Validating authenticity is a problem. GPG is great, but most email users use web-based email nowadays, and there is limited-to-zero browser support for adding digital signatures to messages. 12. HTML is bulky, but there's limited other options for pretty-printing messages (email clients don't often... or ever... support markdown or asciidoc or similar markup). That said, I don't think it's that they are used just because this is the way it has always been. There's plenty of important (and useful) reasons why we use them. Still, I do think it's an archaic and outdated system, which could be pleasantly replaced with an alternative. Aside from the fact that some people still prefer the mailing lists (my opinion may be in the minority), the problem seems to be that there is no simple replacement system which can be substituted. Of the mass communication forums out there, I think email and message boards had some good bits, but the modern social network (G+, FB, etc.) seems to have a reasonable hybrid approach to mass conversations, which allows threaded conversations, direct linking to topics, easily linked external resources (with preview), integration with other tools (email/SMS-to-post/reply), easily linking to an individual to whom one is replying, easily searched and categorized (hashtags), low burden to subscribe/unsubscribe, better identity management, integrated blogging, built-in individual and group chat, two-factor authentication, etc., etc., etc. While email may still have its pros, I *do* think it is archaic and lacking features which inhibit productivity. I think there are better solutions, and it'd be great if we had the resources to think about them and experiment with implementing them for the ASF. -- Christopher L Tubbs II http://gravatar.com/ctubbsii
Re: Mailing lists, sites, ...
On Sun, Jan 18, 2015 at 11:19 AM, jan i j...@apache.org wrote: On 18 January 2015 at 16:48, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: There are many reasons why the ASF requires projects to use its own servers for some items. For example, we couldn't use GitHub until we had built a system that would provide adequate traceability of contributions. Failure to do that would have meant it was no longer possible to provide the legal umbrella necessary to protect developers and reassure users. Such work takes resources. Add to that the fact there is no guarantee that an external service will still be available, in an appropriate form, tomorrow. There is therefore a risk that projects will be damaged by decisions outside of our control. Replacing such lost services requires resources. Finally, one of the advantages of the ASF is that once you know the core principles of how one project works, you know them for all projects. Our response to these issues is to require projects to use ASF provided services for essential items. What has been unclear is what are these essential items and what can our projects expect from the ASF in the non-essential areas. David Nalley and I, as part of our budget planning, are working on identifying what is considered core and what is not. This will help address the confusion and therefore make it easier for project communities to decide whether they can use external services. What we will not be doing is relaxing any of our rules designed to protect the independence and legal governance of our projects. Relaxing would be wrong, but maybe look at tools we require as part of the rules. Not long ago GIT was a not well heard word at ASF, and look where we are now. Rules should define what our requirements are, not the tooling used to reach the requirement. Mailing list is a good example of that, while I agree to the fundamental rule about openess etc...I cannot see why that can only be done on a mailing list. When I speak with new people (like myself), most people find the principle of our rules very good and needed, but not the mixing of rule and tool. just my 2ct. rgds jan i. I agree that those principles need to be at a high level and not worry about tools directly. You can't, however, avoid the fact that it has to be applied. When Infrastructure (as opposed to a project) deploys something, we have to do so with the knowledge that 1 or 200 projects may make use of it, and we have to be able to scale with it. Could projects use forums, in the strictest sense of the word, almost certainly; and some already do for certain types of communication. A good example of this is website publishing. That's all done via svnpubsub today. Lots of projects use git for source code and would love to use git (and gitpubsub) for their website publishing. Technically that isn't a difficult thing to make happen. However that adds much complexity to the work of the group that has to maintain that infrastructure, and thus we won't be doing that. Yes, that means we aren't as agile as we'd like to be, but hopefully it benefits us in the scale department over the long haul. --David
Re: Mailing lists, sites, ...
I've seen this discussion a hundred times or so at Apache, whether it's forums issue trackers or version control. The story is always the same: a handful of software artisans want full uncompromising control over their toolchain. Half the time as is true here what they want is already functionally available to other projects. The other half the time what they want is probably being worked on on a voluntary basis so it's progressing too slowly for some version of too slow. What we need more of in the open source movement are scientific programmers for which an objective reality outside ones own personal biases actually exists. These people already understand why the ubiquity and ease of archival and search available to mailing lists make them a good choice for standardization in our record keeping and official communications. There will always be a place for biased artisans but they need to lead with code not debate. After all git is born out of dissatisfaction with svn, but Linus wrote the tool instead of simply publicly whinging about his hatred for svn. Sent from my iPhone On Jan 18, 2015, at 11:34 AM, David Nalley da...@gnsa.us wrote: On Sun, Jan 18, 2015 at 11:19 AM, jan i j...@apache.org wrote: On 18 January 2015 at 16:48, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: There are many reasons why the ASF requires projects to use its own servers for some items. For example, we couldn't use GitHub until we had built a system that would provide adequate traceability of contributions. Failure to do that would have meant it was no longer possible to provide the legal umbrella necessary to protect developers and reassure users. Such work takes resources. Add to that the fact there is no guarantee that an external service will still be available, in an appropriate form, tomorrow. There is therefore a risk that projects will be damaged by decisions outside of our control. Replacing such lost services requires resources. Finally, one of the advantages of the ASF is that once you know the core principles of how one project works, you know them for all projects. Our response to these issues is to require projects to use ASF provided services for essential items. What has been unclear is what are these essential items and what can our projects expect from the ASF in the non-essential areas. David Nalley and I, as part of our budget planning, are working on identifying what is considered core and what is not. This will help address the confusion and therefore make it easier for project communities to decide whether they can use external services. What we will not be doing is relaxing any of our rules designed to protect the independence and legal governance of our projects. Relaxing would be wrong, but maybe look at tools we require as part of the rules. Not long ago GIT was a not well heard word at ASF, and look where we are now. Rules should define what our requirements are, not the tooling used to reach the requirement. Mailing list is a good example of that, while I agree to the fundamental rule about openess etc...I cannot see why that can only be done on a mailing list. When I speak with new people (like myself), most people find the principle of our rules very good and needed, but not the mixing of rule and tool. just my 2ct. rgds jan i. I agree that those principles need to be at a high level and not worry about tools directly. You can't, however, avoid the fact that it has to be applied. When Infrastructure (as opposed to a project) deploys something, we have to do so with the knowledge that 1 or 200 projects may make use of it, and we have to be able to scale with it. Could projects use forums, in the strictest sense of the word, almost certainly; and some already do for certain types of communication. A good example of this is website publishing. That's all done via svnpubsub today. Lots of projects use git for source code and would love to use git (and gitpubsub) for their website publishing. Technically that isn't a difficult thing to make happen. However that adds much complexity to the work of the group that has to maintain that infrastructure, and thus we won't be doing that. Yes, that means we aren't as agile as we'd like to be, but hopefully it benefits us in the scale department over the long haul. --David
Re: Mailinglists - a tool from the 90s?
Hi, I am new to this list and have been following this thread. I don't know whether I missed this. But loomio is a free software for collaborative decision making processes and its a free software. Do check it out. It's easy to keep track. On January 18, 2015 9:57:44 PM GMT+05:30, Christopher ctubb...@apache.org wrote: On Sun, Jan 18, 2015 at 7:34 AM, Benedikt Ritter brit...@apache.org wrote: [snip] Now I'm curious: Does anybody here really like the use of mailing lists? Or do we all simply go through the struggle of setting up filters etc. just because this is the way it has always been? I absolutely loathe mailing lists: 1. They *feel* like spam (Google often incorrectly identifies ASF mailing list activity as spam). 2. They are difficult to parse (visually) and triage/categorize (subject line conventions help to some degree). 3. They are often full of pages and pages of text, which could be more easily conveyed by a more succinct means, with the best option to provide a link to an external resource (which creates a slight burden on the composer). 4. Long conversations often get forked, and are difficult to follow (esp. in tools like GMail which doesn't thread conversations natively). Even when not forked, they can be difficult to determine whom one is responding to when replies are interspersed. 5. Outages and late-subscribers can get messages at different times, and dealing with backlog is not so easy. 6. The archives are profoundly difficult to navigate and reference (though, that's specific to ASF archives, not necessarily generally true). 7. Filters are useful, but have limited ability to address all the issues. 8. Client-side identity management is a pain, when you have multiple email addresses for different purposes, and the mailing lists expose you to spam. 9. Replying is inefficient and ugly, with different community conventions (top-posting, bottom-posting, inline-posting) on mailing lists. 10. Message sizes when replying is often inefficient. Most people quote the entire previous message, including any previously quoted messages, indenting and wrapping, sending and storing redundant bits which are difficult to read anyway. 11. Validating authenticity is a problem. GPG is great, but most email users use web-based email nowadays, and there is limited-to-zero browser support for adding digital signatures to messages. 12. HTML is bulky, but there's limited other options for pretty-printing messages (email clients don't often... or ever... support markdown or asciidoc or similar markup). That said, I don't think it's that they are used just because this is the way it has always been. There's plenty of important (and useful) reasons why we use them. Still, I do think it's an archaic and outdated system, which could be pleasantly replaced with an alternative. Aside from the fact that some people still prefer the mailing lists (my opinion may be in the minority), the problem seems to be that there is no simple replacement system which can be substituted. Of the mass communication forums out there, I think email and message boards had some good bits, but the modern social network (G+, FB, etc.) seems to have a reasonable hybrid approach to mass conversations, which allows threaded conversations, direct linking to topics, easily linked external resources (with preview), integration with other tools (email/SMS-to-post/reply), easily linking to an individual to whom one is replying, easily searched and categorized (hashtags), low burden to subscribe/unsubscribe, better identity management, integrated blogging, built-in individual and group chat, two-factor authentication, etc., etc., etc. While email may still have its pros, I *do* think it is archaic and lacking features which inhibit productivity. I think there are better solutions, and it'd be great if we had the resources to think about them and experiment with implementing them for the ASF. -- Christopher L Tubbs II http://gravatar.com/ctubbsii -- Sent from my Android device with K-9 Mail. Please excuse my brevity.
Re: Mailing lists, sites, ...
On 18.01.2015 18:10, Joseph Schaefer wrote: After all git is born out of dissatisfaction with svn, but Linus wrote the tool instead of simply publicly whinging about his hatred for svn. You mean, as well as, not instead of. :) -- Brane
Re: Mailinglists - a tool from the 90s?
On 1/18/15 5:53 AM, Claude Warren wrote: I prefer the mailing list because it pushes new concepts to me. Git and such requires that I work harder to get the information. Most of the Apache mailing lists have a high signal to noise ratio. And even the signals I am not interested in don't take that long to dispose of. +1 - even the noisy lists which are, IMO actually a good sign. As others have pointed out already, there are two reasons that we insist that projects have dev lists and adhere to the principle if it did not happen on the list, it did not happen (meaning no decisions can be made elsewhere). 1. The list provides a single point of transparency for the project. It is easy for anyone - regardless of time zone, employment affiliation, cool tools, secret handshakes, etc - to see what is going on now and how we got to where we are. 2. The list serves as an archive of project decisions. There are some significant benefits of mailing lists that alternatives will have to deliver: 3. We can host and archive them on ASF infrastructure, effectively guaranteeing durability and independence. This is very important. The ASF has already outlived quite a few cool collaboration vendors / quasi-OSS watering holes. 4. At base, they traffic in plain ASCII text with headers capturing the critical information necessary to reconstruct discussions. There are lots of tools available to analyze archives. A good question to ask about any suggested alternatives is do they meet the requirements 1. and 2. and share the advantages 3. and 4. or have other advantages. One thing that I agree is a shame is the deterioration of mail clients and archive search tools. Gmail is a disaster. I personally use Thunderbird for all ASF lists. I also use markmail a lot for searching, as it is superior to what we have internally. Phil Claude On Sun, Jan 18, 2015 at 12:34 PM, Benedikt Ritter brit...@apache.org wrote: Hi all, over at the Apache Commons Project, we have a long discussion about our mailing lists. Are they to noisy? Should they be splitted up into sublists? Should individual components go TLP? IMHO Ben McCann summed up the core problem pretty well [1]. Mailing lists are simply a outdated tool from the 90s. They can not compete with tools like github/gitlab that integrate the code with the possibility to do code reviews, disucssions and bugtracking. Now I'm curious: Does anybody here really like the use of mailing lists? Or do we all simply go through the struggle of setting up filters etc. just because this is the way it has always been? Regards, Benedikt [1] http://markmail.org/message/iizay3mmf2msvaf2 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
Re: Mailing lists, sites, ...
On 18 January 2015 at 16:48, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: There are many reasons why the ASF requires projects to use its own servers for some items. For example, we couldn't use GitHub until we had built a system that would provide adequate traceability of contributions. Failure to do that would have meant it was no longer possible to provide the legal umbrella necessary to protect developers and reassure users. Such work takes resources. Add to that the fact there is no guarantee that an external service will still be available, in an appropriate form, tomorrow. There is therefore a risk that projects will be damaged by decisions outside of our control. Replacing such lost services requires resources. Finally, one of the advantages of the ASF is that once you know the core principles of how one project works, you know them for all projects. Our response to these issues is to require projects to use ASF provided services for essential items. What has been unclear is what are these essential items and what can our projects expect from the ASF in the non-essential areas. David Nalley and I, as part of our budget planning, are working on identifying what is considered core and what is not. This will help address the confusion and therefore make it easier for project communities to decide whether they can use external services. What we will not be doing is relaxing any of our rules designed to protect the independence and legal governance of our projects. Relaxing would be wrong, but maybe look at tools we require as part of the rules. Not long ago GIT was a not well heard word at ASF, and look where we are now. Rules should define what our requirements are, not the tooling used to reach the requirement. Mailing list is a good example of that, while I agree to the fundamental rule about openess etc...I cannot see why that can only be done on a mailing list. When I speak with new people (like myself), most people find the principle of our rules very good and needed, but not the mixing of rule and tool. just my 2ct. rgds jan i. Sent from my Windows Phone From: Jay Vyasmailto:jayunit100.apa...@gmail.com Sent: 1/18/2015 7:37 AM To: dev@community.apache.orgmailto:dev@community.apache.org Subject: Mailing lists, sites, ... Hi Apache . Every so often we get the question come up: does Apache infra allow/support . The answer is sometimes not yet and related to the fact that there are 100s of projects that require uniformity at Apache, and it would be chaos of every new project was allowed a new infrastructure. Idea: Now that project infrastructure is easier using things like github and static sites or google groups forums etc Maybe the ASF could loosely agree to support some types of alternative project tooling, as long all project conversations and decisions and artifacts were centrally archived at Apache?This can easily be done by simply adding an Apache email address to a monitor a particular forum , or github issues notifications or whatever. Benefits of looser grip on community infrastructure: The main benefit of Apache in a post github era is not the storage and mail servers - it's the centralized archiving, community process, and transparent workflow. And those things can be implemented with any technology. So, my general thought is : Apache still can enforce its core principals while loosening some of the more granular rules around infrastructure . Maybe the time is now (or maybe not) to start allowing projects to branch out their tooling ... While still supporting the tried and true mechanisms and not pressuring infra every time someone wants to use some new email alternative or site hosting solution. In any case looking forward to feedback on this from some Apache veterans .
Re: Mailinglists - a tool from the 90s?
On Sun, Jan 18, 2015 at 7:34 AM, Benedikt Ritter brit...@apache.org wrote: Hi all, over at the Apache Commons Project, we have a long discussion about our mailing lists. Are they to noisy? Should they be splitted up into sublists? Should individual components go TLP? IMHO Ben McCann summed up the core problem pretty well [1]. Mailing lists are simply a outdated tool from the 90s. They can not compete with tools like github/gitlab that integrate the code with the possibility to do code reviews, disucssions and bugtracking. So there are reasons that we choose to mandate mailing lists, and one of them is traceability. People know where to look for decisions; ten years down the road we know where to look for decisions and know that we are retaining the information. Github is a great tool for review workflows, but it isn't mutually exclusive with mailing lists. Infra built integration[1] that lets you have both worlds. Every discussion comment from github copied to a mailing list, and every mailing list comment in that thread copied back to Github. Many projects (more than 40) are using this to great effect - it's become a core part of their contribution and review workflow, many have tied it into Jenkins or Travis so they get CI feedback in the process. --David [1] https://blogs.apache.org/infra/entry/improved_integration_between_apache_and
Re: Mailinglists - a tool from the 90s?
With respect to search: There's an ASF project, some of you might have heard of it, and, rumor has it, they build a pretty good full-text search engine. So, instead of complaining about the quality of MarkMail, perhaps we could address this end of things by looking into more sophisticated use of, well, Apache Solr. I'm starting a thread on infra@ to look into it; people with specific desiderata should pile on. If you can find it.
Re: Mailinglists - a tool from the 90s?
Ross beat me to the punch On Sunday, January 18, 2015, Ross Gardler (MS OPEN TECH) ross.gard...@microsoft.com wrote: For me any alternative would still have to push everything into my inbox where I can use a my preferred tools, each developed and matured over many years, to help me process the volume of communications I need (filters, archives, calendars etc.) +1000 And I should be able to interact back by just replying to emails. If I have to context switch just to reply that's a big no. Ross Sent from my Windows Phone From: Benedikt Rittermailto:brit...@apache.org javascript:; Sent: 1/18/2015 4:35 AM To: dev@community.apache.org javascript:;mailto: dev@community.apache.org javascript:; Subject: Mailinglists - a tool from the 90s? Hi all, over at the Apache Commons Project, we have a long discussion about our mailing lists. Are they to noisy? Should they be splitted up into sublists? Should individual components go TLP? IMHO Ben McCann summed up the core problem pretty well [1]. Mailing lists are simply a outdated tool from the 90s. They can not compete with tools like github/gitlab that integrate the code with the possibility to do code reviews, disucssions and bugtracking. Now I'm curious: Does anybody here really like the use of mailing lists? Or do we all simply go through the struggle of setting up filters etc. just because this is the way it has always been? Regards, Benedikt [1] http://markmail.org/message/iizay3mmf2msvaf2 -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter -- Sent from my phone
