[PHP-DEV] Move internals discussion to a better medium
Hello internals! I wanted to propose a change to how PHP discussions are made. Currently, PHP discussions are held on the various mailing lists, managed by an old mailing list system, without any proper alternative interface to follow and respond outside of mailing. The discussion is hidden away, deep within the mails and the archives, searching is nigh impossible for someone from the outside. Moreover, subscribing to internals and starting discussion has a *very high entry bar*, which is bad for any open source project (PHP is still considered an open source project, yes?). For example, ask a friend to try and find how to join in on the conversation, without mentioning the mailing list or the word "internals". I propose that internals discussion to be moved (eventually entirely) to a different medium, where the example I have in mind is GitHub issues (but that is up for discussion). - Every developer worth his salt has a GitHub account. Finding the php project and looking at the issues is trivial. - GitHub issues can reference to people by name (triggering an explicit notification). - GitHub issues can reference other issues (currently impossible with the mailing list, unless you link to some archive, and then you can't really participate in the discussion, nor you have a guaranteed context for the rest of the discussion) - GitHub issues can be read and interacted with, from email. (Responding to an issue/commit comment notification will actually respond to the thread) - GitHub issues can reference commits directly. - GitHub commits can reference issues directly. - You can close GitHub issues. - GitHub issues are searchable. You have tags. - GitHub issues can be associated with milestones for easy reference. - You can comment on specific lines of a commit, and can reference files and line numbers from issue comments directly. - You don't need to maintain GitHub, like you do with the current system - Markdown formatting! There are probably more advantages I forgot to mention, but any developer who's familiar with GitHub (or BitBucket, or practically any other form of Git integration) knows of these free features and advantages, and most of them use them and take them for granted. Now, that's not to say the current system has no advantages over the current one. A few disadvantages of GitHub: - GitHub may be down (although I can probably count on one hand how many times that happened in the past several years) - GitHub's mailing system is not as robust as the mailing-list software. People who are exclusively used to emails will have to get used to a slightly different interface. - Moving to GitHub (or any other medium) would take some thinking and work done on the side of the people of internals. Personally, I think the advantages would seriously overweigh the disadvantages. PHP would enjoy a more robust discussion system, and a more open form of discussion, involving more people and more opinions. (I also have a matching workflow adjustment for the RFC process, but that can be discussed later)
[PHP-DEV] Re: Move internals discussion to a better medium
On Sun, Aug 2, 2015 at 3:38 PM Dor Tchizik wrote: > On Sun, Aug 2, 2015 at 3:32 PM Markus Malkusch wrote: > >> Dor Tchizik wrote: >> >> > Currently, PHP discussions are held on the various mailing lists, >> managed >> > by an old mailing list system, without any proper alternative interface >> to >> > follow and respond outside of mailing. >> >> What wrong with <news://news.php.net/>? >> > > No threads, no searchability, no ability to respond. > > >> >> > I propose that internals discussion to be moved (eventually entirely) >> to a >> > different medium, where the example I have in mind is GitHub issues >> >> That's an issue tracker (and to be honest not one of the best). > > > Like I said, GitHub is an example, the actual medium can be discussed. > Also, what's being discussed on internals are issues. Definitely. > > >> I don't see any benefit there. Furthermore participating requires a >> github.com >> registration whereas this medium is free to use. And you know what happend >> to the last big player (namely sourceforge)? Github can go loko as well. >> > > "Any developer worth their salt has a GitHub account". Also, disregarding > the fact that GitHub going loco is not likely (because there are other big > players on the market), even a privately hosted (but publicly visible) > issue tracker for PHP, with a modern interface is still infinitely better > than the mailing list. > > >> >> >- GitHub issues can reference other issues (currently impossible with >> >the mailing list >> >> Let's reference something then <news:e6.64.22108.e69f7...@pb1.pair.com> >> > > I don't know how you see it, I got a mailto: link to that address. > > >> >> >- GitHub issues are searchable. You have tags. >> >> Newsserver are searchable as well. At least you could wrap the current >> infrastructure easily into a search engine. >> > > Perhaps, but an issue tracker gives you that feature for free, and you > don't need to implement it (good search is hard). > > >> >> Markus Malkusch >> >
Re: [PHP-DEV] Move internals discussion to a better medium
On Sun, Aug 2, 2015 at 5:29 PM Andreas Heigl wrote: > Hi Dor. > > > Am 02.08.2015 um 14:01 schrieb Dor Tchizik : > > > > Hello internals! > > > > I wanted to propose a change to how PHP discussions are made. > > > > Currently, PHP discussions are held on the various mailing lists, managed > > by an old mailing list system, without any proper alternative interface > to > > follow and respond outside of mailing. > > The discussion is hidden away, deep within the mails and the archives, > > searching is nigh impossible for someone from the outside. > > Moreover, subscribing to internals and starting discussion has a *very > high > > entry bar*, which is bad for any open source project (PHP is still > > considered an open source project, yes?). For example, ask a friend to > try > > and find how to join in on the conversation, without mentioning the > mailing > > list or the word "internals". > > > > I propose that internals discussion to be moved (eventually entirely) to > a > > different medium, where the example I have in mind is GitHub issues (but > > that is up for discussion). > > > > > > - Every developer worth his salt has a GitHub account. Finding the php > > project and looking at the issues is trivial. > > - GitHub issues can reference to people by name (triggering an explicit > > notification). > > - GitHub issues can reference other issues (currently impossible with > > the mailing list, unless you link to some archive, and then you can't > > really participate in the discussion, nor you have a guaranteed > context for > > the rest of the discussion) > > - GitHub issues can be read and interacted with, from email. > (Responding > > to an issue/commit comment notification will actually respond to the > thread) > > - GitHub issues can reference commits directly. > > - GitHub commits can reference issues directly. > > - You can close GitHub issues. > > - GitHub issues are searchable. You have tags. > > - GitHub issues can be associated with milestones for easy reference. > > - You can comment on specific lines of a commit, and can reference > files > > and line numbers from issue comments directly. > > - You don't need to maintain GitHub, like you do with the current > system > > - Markdown formatting! > > > > There are probably more advantages I forgot to mention, but any developer > > who's familiar with GitHub (or BitBucket, or practically any other form > of > > Git integration) knows of these free features and advantages, and most of > > them use them and take them for granted. > > > > Now, that's not to say the current system has no advantages over the > > current one. > > A few disadvantages of GitHub: > > > > - GitHub may be down (although I can probably count on one hand how > many > > times that happened in the past several years) > > - GitHub's mailing system is not as robust as the mailing-list > software. > > People who are exclusively used to emails will have to get used to a > > slightly different interface. > > - Moving to GitHub (or any other medium) would take some thinking and > > work done on the side of the people of internals. > > > > Personally, I think the advantages would seriously overweigh the > > disadvantages. PHP would enjoy a more robust discussion system, and a > more > > open form of discussion, involving more people and more opinions. > > > > (I also have a matching workflow adjustment for the RFC process, but that > > can be discussed later) > > Is this the - in recent times becoming more and more popular - try to > replace an open soure interface ( news://, smtp://, irc://, jabber://) with > a closed source implementation (github, slack, hiphop, bitbucket)? > Nah, an open source Git integration with an issue tracker, or even a simple forum would be tons better than the mailing list. GitHub is just an example, but I think it has many useful features. > > The mailinglist might be far from perfect (which some people also say > about PHP so there's a good match) but it is a well established way of > communication in the PHP-community. I strongly believe that it would be > counterproductive to change the way of communication of the core > contributors for the sake of probanly getting two or three more > contributors. At least as long as the alternative is at least as faulty as > the current way of communication. > > What makes you think that two or three more contributors is what you'd get?
Re: [PHP-DEV] Move internals discussion to a better medium
This is what I think. The best way to deter the community from making contributions is to make it hard to contribute. My C/C++ savvy buddy told me about an awesome feature he wants to see in iojs, I can tell him to go on GitHub and raise the issue, discussion took place, and he'd submitted a pull request, which subsequently got accepted. The entire process took two days, mainly due to timezone differences. Everyone were helpful and to the point. Now, I get that the RFC process in PHP is different, but why is it that to even GET on the mailing list one needs to go through seven hells, only to be in the discussion (often completely irrelevant to what he's trying to do) for several weeks or months, to get Karma, and only then may he submit an RFC? Why can't someone just open an issue, and have an RFC up and ready the next day (or even the next week)? It's this exact approach that pushes valuable community members away, several members of internals whom I value had left internals for various reasons, mostly regarding the atmosphere in the mailing list. And the way you improve the atmosphere is to get more people, more eyes, more opinions. On Sun, Aug 2, 2015 at 10:10 PM Marcio Almada wrote: > Hi, > > 2015-08-02 9:01 GMT-03:00 Dor Tchizik : > > Hello internals! > > > > I wanted to propose a change to how PHP discussions are made. > > > > Currently, PHP discussions are held on the various mailing lists, managed > > by an old mailing list system, without any proper alternative interface > to > > follow and respond outside of mailing. > > The discussion is hidden away, deep within the mails and the archives, > > searching is nigh impossible for someone from the outside. > > Moreover, subscribing to internals and starting discussion has a *very > high > > entry bar*, which is bad for any open source project (PHP is still > > considered an open source project, yes?). For example, ask a friend to > try > > and find how to join in on the conversation, without mentioning the > mailing > > list or the word "internals". > > > > I propose that internals discussion to be moved (eventually entirely) to > a > > different medium, where the example I have in mind is GitHub issues (but > > that is up for discussion). > > > > > >- Every developer worth his salt has a GitHub account. Finding the php > >project and looking at the issues is trivial. > >- GitHub issues can reference to people by name (triggering an > explicit > >notification). > >- GitHub issues can reference other issues (currently impossible with > >the mailing list, unless you link to some archive, and then you can't > >really participate in the discussion, nor you have a guaranteed > context for > >the rest of the discussion) > >- GitHub issues can be read and interacted with, from email. > (Responding > >to an issue/commit comment notification will actually respond to the > thread) > >- GitHub issues can reference commits directly. > >- GitHub commits can reference issues directly. > >- You can close GitHub issues. > >- GitHub issues are searchable. You have tags. > >- GitHub issues can be associated with milestones for easy reference. > >- You can comment on specific lines of a commit, and can reference > files > >and line numbers from issue comments directly. > >- You don't need to maintain GitHub, like you do with the current > system > >- Markdown formatting! > > > > There are probably more advantages I forgot to mention, but any developer > > who's familiar with GitHub (or BitBucket, or practically any other form > of > > Git integration) knows of these free features and advantages, and most of > > them use them and take them for granted. > > > > Now, that's not to say the current system has no advantages over the > > current one. > > A few disadvantages of GitHub: > > > >- GitHub may be down (although I can probably count on one hand how > many > >times that happened in the past several years) > >- GitHub's mailing system is not as robust as the mailing-list > software. > >People who are exclusively used to emails will have to get used to a > >slightly different interface. > >- Moving to GitHub (or any other medium) would take some thinking and > >work done on the side of the people of internals. > > > > Personally, I think the advantages would seriously overweigh the > > disadvantages. PHP would enjoy a more robust discussion system, and a > more > > open form of discussion, involving
Re: [PHP-DEV] Move internals discussion to a better medium
I already have. iojs (and soon, nodejs), as well as Rust which was mentioned by someone else. On Sun, Aug 2, 2015 at 11:04 PM Stig Bakken wrote: > On Sun, Aug 2, 2015 at 2:02 PM Dor Tchizik wrote: > >> Hello internals! >> >> I wanted to propose a change to how PHP discussions are made. >> >> Currently, PHP discussions are held on the various mailing lists, managed >> by an old mailing list system, without any proper alternative interface to >> follow and respond outside of mailing. >> The discussion is hidden away, deep within the mails and the archives, >> searching is nigh impossible for someone from the outside. >> Moreover, subscribing to internals and starting discussion has a *very >> high >> entry bar*, which is bad for any open source project (PHP is still >> considered an open source project, yes?). For example, ask a friend to try >> and find how to join in on the conversation, without mentioning the >> mailing >> list or the word "internals". >> >> I propose that internals discussion to be moved (eventually entirely) to a >> different medium, where the example I have in mind is GitHub issues (but >> that is up for discussion). >> >> >>- Every developer worth his salt has a GitHub account. Finding the php > > >>project and looking at the issues is trivial. >> >- GitHub issues can reference to people by name (triggering an explicit >>notification). >>- GitHub issues can reference other issues (currently impossible with > > >>the mailing list, unless you link to some archive, and then you can't >>really participate in the discussion, nor you have a guaranteed >> context for >>the rest of the discussion) >> >- GitHub issues can be read and interacted with, from email. (Responding > > >>to an issue/commit comment notification will actually respond to the >> thread) >> >- GitHub issues can reference commits directly. >>- GitHub commits can reference issues directly. >>- You can close GitHub issues. >>- GitHub issues are searchable. You have tags. >>- GitHub issues can be associated with milestones for easy reference. >>- You can comment on specific lines of a commit, and can reference >> files > > >>and line numbers from issue comments directly. >> >- You don't need to maintain GitHub, like you do with the current system >>- Markdown formatting! > > >> >> There are probably more advantages I forgot to mention, but any developer >> who's familiar with GitHub (or BitBucket, or practically any other form of >> Git integration) knows of these free features and advantages, and most of >> them use them and take them for granted. >> >> Now, that's not to say the current system has no advantages over the >> current one. >> A few disadvantages of GitHub: >> >>- GitHub may be down (although I can probably count on one hand how >> many > > >>times that happened in the past several years) >> >- GitHub's mailing system is not as robust as the mailing-list software. > > >>People who are exclusively used to emails will have to get used to a >>slightly different interface. >> >- Moving to GitHub (or any other medium) would take some thinking and > > >>work done on the side of the people of internals. >> >> Personally, I think the advantages would seriously overweigh the >> disadvantages. PHP would enjoy a more robust discussion system, and a more >> open form of discussion, involving more people and more opinions. >> >> (I also have a matching workflow adjustment for the RFC process, but that >> can be discussed later) >> > > Are you being serious? Can you provide examples of projects that have > successfully replaced their developer mailing lists with GitHub issues? > > - Stig > >