Newsgroups: php.internals
Path: news.php.net
Xref: news.php.net php.internals:87528
Mailing-List: contact internals-help@lists.php.net; run by ezmlm
Received-SPF: pass (pb1.pair.com: domain gmail.com designates 209.85.213.53 as permitted sender)
MIME-Version: 1.0
References: <CAGbiJu-No6nmVt6O05e6oiEJ1jBD-T2fXxLJSMpksf2CE_9HJw@mail.gmail.com>
 <CAOsHV+v7Rwg=DEhtpqc3XzwDqw1Q7aX3_Mvu8FUZhVLeM77jHA@mail.gmail.com>
In-Reply-To: <CAOsHV+v7Rwg=DEhtpqc3XzwDqw1Q7aX3_Mvu8FUZhVLeM77jHA@mail.gmail.com>
Date: Sun, 02 Aug 2015 19:17:54 +0000
Message-ID: <CAGbiJu9_10HU2xCr=rUp72hxPgyvXxVf42s67W_4WorNCANpLA@mail.gmail.com>
To: Marcio Almada <marcio.web2@gmail.com>, Dor Tchizik <dor@tchizik.com>
Cc: PHP Internals <internals@lists.php.net>
Content-Type: multipart/alternative; boundary=001a1136b58c85412e051c58e915
Subject: Re: [PHP-DEV] Move internals discussion to a better medium
From: dor@tchizik.com (Dor Tchizik)

--001a1136b58c85412e051c58e915
Content-Type: text/plain; charset=UTF-8

This is what I think. The best way to deter the community from making
contributions is to make it hard to contribute. My C/C++ savvy buddy told
me about an awesome feature he wants to see in iojs, I can tell him to go
on GitHub and raise the issue, discussion took place, and he'd submitted a
pull request, which subsequently got accepted. The entire process took two
days, mainly due to timezone differences. Everyone were helpful and to the
point.

Now, I get that the RFC process in PHP is different, but why is it that to
even GET on the mailing list one needs to go through seven hells, only to
be in the discussion (often completely irrelevant to what he's trying to
do) for several weeks or months, to get Karma, and only then may he submit
an RFC? Why can't someone just open an issue, and have an RFC up and ready
the next day (or even the next week)?

It's this exact approach that pushes valuable community members away,
several members of internals whom I value had left internals for various
reasons, mostly regarding the atmosphere in the mailing list. And the way
you improve the atmosphere is to get more people, more eyes, more opinions.

On Sun, Aug 2, 2015 at 10:10 PM Marcio Almada <marcio.web2@gmail.com> wrote:

> 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.
>

--001a1136b58c85412e051c58e915--