Hi,

2015-08-02 9:01 GMT-03:00 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)

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.

-- 
PHP Internals - PHP Runtime Development Mailing List
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to