Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87534
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.212.179 as permitted sender)
MIME-Version: 1.0
References: <CAGbiJu-No6nmVt6O05e6oiEJ1jBD-T2fXxLJSMpksf2CE_9HJw@mail.gmail.com>
In-Reply-To: <CAGbiJu-No6nmVt6O05e6oiEJ1jBD-T2fXxLJSMpksf2CE_9HJw@mail.gmail.com>
Date: Sun, 02 Aug 2015 20:03:50 +0000
Message-ID: <CABM2sytH3ed7LeQbzO39d5d8mP=krOQbPJzyPXguNTpPDx3=5Q@mail.gmail.com>
To: Dor Tchizik <dor@tchizik.com>, PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=f46d044280ccbf3120051c598d66
Subject: Re: [PHP-DEV] Move internals discussion to a better medium
From: stig@stigbakken.com (Stig Bakken)

--f46d044280ccbf3120051c598d66
Content-Type: text/plain; charset=UTF-8

On Sun, Aug 2, 2015 at 2:02 PM Dor Tchizik <dor@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

--f46d044280ccbf3120051c598d66--