On Sun, Aug 2, 2015 at 5:29 PM Andreas Heigl <andr...@heigl.org> wrote:

> Hi Dor.
>
> > Am 02.08.2015 um 14:01 schrieb Dor Tchizik <d...@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)
>
> Is this the - in recent times becoming more and more popular - try to
> replace an open soure interface ( news://, smtp://, irc://, jabber://) with
> a closed source implementation (github, slack, hiphop, bitbucket)?
>

Nah, an open source Git integration with an issue tracker, or even a simple
forum would be tons better than the mailing list. GitHub is just an
example, but I think it has many useful features.


>
> The mailinglist might be far from perfect (which some people also say
> about PHP so there's a good match) but it is a well established way of
> communication in the PHP-community. I strongly believe that it would be
> counterproductive to change the way of communication of the core
> contributors for the sake of probanly getting two or three more
> contributors. At least as long as the alternative is at least as faulty as
> the current way of communication.
>
>
What makes you think that two or three more contributors is what you'd get?
The nodejs org on GitHub is almost 400 strong.


> And to be honnest: For me it shows a certain understanding of the way the
> web works when you are able to setup your tools to be able to follow the
> discussions 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.
>

Oh, I'm able to set my tools. The question is, am I willing to put this
much time and effort, when *you're* (you as in the PHP core team) should be
asking and encouraging *me* for contribution, and end up saying things like
"if you can't even take 30 minutes of your life reading and setting up your
environment, don't bother contributing". Here's a hint, no one does that. I
(and many other people) have better things to do with their time, and
they'll take their valuable input and experience into a different project
that's more accessible to them.

Reply via email to