Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87501
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.51 as permitted sender)
MIME-Version: 1.0
Date: Sun, 02 Aug 2015 12:01:57 +0000
Message-ID: <CAGbiJu-No6nmVt6O05e6oiEJ1jBD-T2fXxLJSMpksf2CE_9HJw@mail.gmail.com>
To: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1136b58c76299c051c52d252
Subject: Move internals discussion to a better medium
From: dor@tchizik.com (Dor Tchizik)

--001a1136b58c76299c051c52d252
Content-Type: text/plain; charset=UTF-8

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)

--001a1136b58c76299c051c52d252--