Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87512
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: error (pb1.pair.com: domain heigl.org from 195.191.240.18 cause and error)
Content-Type: text/plain;
	charset=us-ascii
Mime-Version: 1.0 (1.0)
In-Reply-To: <CAGbiJu-No6nmVt6O05e6oiEJ1jBD-T2fXxLJSMpksf2CE_9HJw@mail.gmail.com>
Date: Sun, 2 Aug 2015 16:29:54 +0200
Cc: PHP Internals <internals@lists.php.net>
Content-Transfer-Encoding: quoted-printable
Message-ID: <91CAFBE6-9598-41AD-862A-643EDB69452E@heigl.org>
References: <CAGbiJu-No6nmVt6O05e6oiEJ1jBD-T2fXxLJSMpksf2CE_9HJw@mail.gmail.com>
To: Dor Tchizik <dor@tchizik.com>
Subject: Re: [PHP-DEV] Move internals discussion to a better medium
From: andreas@heigl.org (Andreas Heigl)

Hi Dor.=20

> Am 02.08.2015 um 14:01 schrieb Dor Tchizik <dor@tchizik.com>:
>=20
> Hello internals!
>=20
> I wanted to propose a change to how PHP discussions are made.
>=20
> 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 hig=
h
> 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 mailin=
g
> list or the word "internals".
>=20
> 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).
>=20
>=20
>   - 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 f=
or
>   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 thr=
ead)
>   - 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!
>=20
> 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.
>=20
> Now, that's not to say the current system has no advantages over the
> current one.
> A few disadvantages of GitHub:
>=20
>   - 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.
>=20
> 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.
>=20
> (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 replac=
e an open soure interface ( news://, smtp://, irc://, jabber://) with a clos=
ed source implementation (github, slack, hiphop, bitbucket)?

The mailinglist might be far from perfect (which some people also say about P=
HP so there's a good match) but it is a well established way of communicatio=
n in the PHP-community. I strongly believe that it would be counterproductiv=
e to change the way of communication of the core contributors for the sake o=
f probanly getting two or three more contributors. At least as long as the a=
lternative is at least as faulty as the current way of communication.=20

And to be honnest: For me it shows a certain understanding of the way the we=
b works when you are able to setup your tools to be able to follow the discu=
ssions 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.=20

Cheers

Andreas
--=20
Andreas Heigl
andreas@heigl.org=