On Sun, Aug 2, 2015 at 5:29 PM Andreas Heigl <andr...@heigl.org> wrote:
> Hi Dor. > > > Am 02.08.2015 um 14:01 schrieb Dor Tchizik <d...@tchizik.com>: > > > > 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? The nodejs org on GitHub is almost 400 strong. > And to be honnest: For me it shows a certain understanding of the way the > web works when you are able to setup your tools to be able to follow the > discussions on internals. And I'm not sure Whether I want someone messing > arround with the language that powers 80% of the WorldWideWeb who isn't > able to get his tools set up properly. But that's just my 2 arrogant cent. > Oh, I'm able to set my tools. The question is, am I willing to put this much time and effort, when *you're* (you as in the PHP core team) should be asking and encouraging *me* for contribution, and end up saying things like "if you can't even take 30 minutes of your life reading and setting up your environment, don't bother contributing". Here's a hint, no one does that. I (and many other people) have better things to do with their time, and they'll take their valuable input and experience into a different project that's more accessible to them.
