Re: Move internals discussion to a better medium

On Sun, Aug 2, 2015 at 2:02 PM Dor Tchizik <dor@tchizik.com> wrote: > 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) > Are you being serious? Can you provide examples of projects that have successfully replaced their developer mailing lists with GitHub issues? - Stig