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 <s...@stigbakken.com> wrote: > On Sun, Aug 2, 2015 at 2:02 PM Dor Tchizik <d...@tchizik.com> 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 > >
