Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87527
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.160.171 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <CAGbiJu-No6nmVt6O05e6oiEJ1jBD-T2fXxLJSMpksf2CE_9HJw@mail.gmail.com>
References: <CAGbiJu-No6nmVt6O05e6oiEJ1jBD-T2fXxLJSMpksf2CE_9HJw@mail.gmail.com>
Date: Sun, 2 Aug 2015 16:10:28 -0300
Message-ID: <CAOsHV+v7Rwg=DEhtpqc3XzwDqw1Q7aX3_Mvu8FUZhVLeM77jHA@mail.gmail.com>
To: Dor Tchizik <dor@tchizik.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: text/plain; charset=UTF-8
Subject: Re: [PHP-DEV] Move internals discussion to a better medium
From: marcio.web2@gmail.com (Marcio Almada)

Hi,

2015-08-02 9:01 GMT-03:00 Dor Tchizik <dor@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)

As you pointed github issues, it's worth noting that Rust internals
already use github to manage RFCs:
https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AT-lang

For general discussion and pre RFCs they are using their own discuss
instance. You can login with github in 2 clicks or simply lurk and
search through the threads: https://internals.rust-lang.org/

My 2 cents is that this was an exemplary way to get the community
onboard their project.

Marcio.