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)
Dor Tchizik wrote:
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.
What wrong with news://news.php.net/?
I propose that internals discussion to be moved (eventually entirely) to a
different medium, where the example I have in mind is GitHub issues
That's an issue tracker (and to be honest not one of the best). I don't see
any benefit there. Furthermore participating requires a github.com
registration whereas this medium is free to use. And you know what happend
to the last big player (namely sourceforge)? Github can go loko as well.
- GitHub issues can reference other issues (currently impossible with
the mailing list
Let's reference something then news:E6.64.22108.E69F7B55@pb1.pair.com
- GitHub issues are searchable. You have tags.
Newsserver are searchable as well. At least you could wrap the current
infrastructure easily into a search engine.
Markus Malkusch
2015-08-02 14:32 GMT+02:00 Markus Malkusch markus@malkusch.de:
Dor Tchizik wrote:
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.What wrong with news://news.php.net/?
That's a joke, right?
I propose that internals discussion to be moved (eventually entirely) to
a
different medium, where the example I have in mind is GitHub issuesThat's an issue tracker (and to be honest not one of the best). I don't see
any benefit there.
We're discussing issues here, so what's wrong with an issue tracker?
I can see more than one benefit. Probably most important is that you can
follow just some things, instead of getting all the mails. Additionally, you
can ping people, that's not possible here, most mails are just "reply all"
messages.
Furthermore participating requires a github.com
registration whereas this medium is free to use.
GitHub is free as well.
And you know what happend
to the last big player (namely sourceforge)? Github can go loko as well.
- GitHub issues can reference other issues (currently impossible with
the mailing listLet's reference something then news:E6.64.22108.E69F7B55@pb1.pair.com
That's a mailto link for me as well.
- GitHub issues are searchable. You have tags.
Newsserver are searchable as well. At least you could wrap the current
infrastructure easily into a search engine.
If you want to build and provide a good search engine around it with a nice
interface,
that's another possible solution, but it's something that needs to be built
and maintained.
Regards, Niklas
Markus Malkusch
Niklas Keller wrote:
2015-08-02 14:32 GMT+02:00 Markus Malkusch markus@malkusch.de:
What wrong with news://news.php.net/?
That's a joke, right?
No it's not, why should it? You did notice the news:// scheme, did you?
We're discussing issues here, so what's wrong with an issue tracker?
Ok, that's a valid point.
I can see more than one benefit. Probably most important is that you can
follow just some things, instead of getting all the mails. Additionally,
you can ping people
I don't see that point. Newsreader can follow discussions as well. And what
benefit has pinging, compared to a direct email?
Let's reference something then news:E6.64.22108.E69F7B55@pb1.pair.com
That's a mailto link for me as well.
Well, that's because you are using a mail client. OP was complaining about
the limited interfaces. Use a Newsreader and there you have your reference.
Even Google is able to follow that.
If you want to build and provide a good search engine around it
I don't, news.php.net is public and search engines for news server do exist.
Google once did search them as well, don't know how it is nowadays though.
Markus Malkusch
Niklas Keller wrote:
2015-08-02 14:32 GMT+02:00 Markus Malkusch markus@malkusch.de:
What wrong with news://news.php.net/?
That's a joke, right?
No it's not, why should it? You did notice the news:// scheme, did you?
We're discussing issues here, so what's wrong with an issue tracker?
Ok, that's a valid point.
I can see more than one benefit. Probably most important is that you can
follow just some things, instead of getting all the mails. Additionally,
you can ping peopleI don't see that point. Newsreader can follow discussions as well. And what
benefit has pinging, compared to a direct email?Let's reference something then news:E6.64.22108.E69F7B55@pb1.pair.com
That's a mailto link for me as well.
Well, that's because you are using a mail client. OP was complaining about
the limited interfaces. Use a Newsreader and there you have your reference.
Even Google is able to follow that.If you want to build and provide a good search engine around it
I don't, news.php.net is public and search engines for news server do exist.
Google once did search them as well, don't know how it is nowadays though.Markus Malkusch
You have to admit, NNTP news is an aging technology, with fewer and
fewer readers available as time goes on. Nowadays (for graphical
clients), there's Pan, and Thunderbird, and...? I use Thunderbird at the
moment, because I didn't want to fill up my email, and there aren't too
many readers. Heck, Thunderbird is technically a "discontinued" product.
--
Stephen Coakley
Heck, Thunderbird is technically a "discontinued"
product.
O/T, but to my knowledge Thunderbird is not discontinued, it's just changed management because Mozilla are no longer paying for it. The new management are actively developing it, but they're probably short of cash...
Heck, Thunderbird is technically a "discontinued"
product.O/T, but to my knowledge Thunderbird is not discontinued, it's just changed management because Mozilla are no longer paying for it. The new management are actively developing it, but they're probably short of cash...
Oh, my mistake.
Thunderbird works great for reading nested replies and past archives,
but replying has about a 50% chance of success for me. Oh well.
--
Stephen Coakley
Thunderbird works great for reading nested replies and past archives,
but replying has about a 50% chance of success for me. Oh well.
I'm up to 24Gb of history over some 20 years and despite attempts by
some developers to mess it up, Thunderbird does the job reasonably well.
I'd prefer to be back on Seamonkey, but that has lost the ability to
handle so big an archive, and in trying to 'keep up' with Firefox and
Thunderbird it's no longer providing what a single suite used to
provide. But then my Linux desktop fills in the gaps so I don't need
Thunderbird to have a bloody calendar or Firefox to muscle in on the
same space. Thunderbird does reliably handle emails in and emails out
without a problem, and I don't need to go on-line to read the traffic,
ore scan the history ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Thunderbird works great for reading nested replies and past archives,
but replying has about a 50% chance of success for me. Oh well.I'm up to 24Gb of history over some 20 years and despite attempts by
some developers to mess it up, Thunderbird does the job reasonably well.
I'd prefer to be back on Seamonkey, but that has lost the ability to
handle so big an archive, and in trying to 'keep up' with Firefox and
Thunderbird it's no longer providing what a single suite used to
provide. But then my Linux desktop fills in the gaps so I don't need
Thunderbird to have a bloody calendar or Firefox to muscle in on the
same space. Thunderbird does reliably handle emails in and emails out
without a problem, and I don't need to go on-line to read the traffic,
ore scan the history ...
I don't mean to sound rude, but when have you ever needed to access a
really old message while simultaneously not having Internet access? I
just can't imagine needing to do such a thing. Not saying it's wrong for
you to do so.
--
Stephen Coakley
I don't mean to sound rude, but when have you ever needed to access a
really old message while simultaneously not having Internet access? I
just can't imagine needing to do such a thing. Not saying it's wrong for
you to do so.
When the local internet is down ... will be at least another three years
before we get considered again for high speed broadband, but if I drag a
cable across the nearby bypass I could plug into the next cabinet along
I could get it. 3G is a joke I've been paying for for years and even
Vodafone admit they have probably not provided me more than a days
access in 10 years! But there are people out there far worse off than me
for a broadband connection?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
On Mo. Aug. 03 2015 10:40:14 Lester Caine wrote:
I don't mean to sound rude, but when have you ever needed to access a
really old message while simultaneously not having Internet access? I
just can't imagine needing to do such a thing. Not saying it's wrong for
you to do so.When the local internet is down ... will be at least another three years
before we get considered again for high speed broadband, but if I drag a
cable across the nearby bypass I could plug into the next cabinet along
I could get it. 3G is a joke I've been paying for for years and even
Vodafone admit they have probably not provided me more than a days
access in 10 years! But there are people out there far worse off than me
for a broadband connection?
Yep. Good connection is rare in the outlands in most cases. I live in between places, so I often rely on my phone’s internet. In fact, it should always be considered that people may have rare/bad internet access - but still want to contribute.
For instance, I spent about two weeks in Kenya. Internet down there is like 10kb/s. And Kenya is one of many countries with a bad internet connectivity.
Just my two cents.
Stephen Coakley wrote:
You have to admit, NNTP news is an aging technology
Sadly admited, I didn't touch it since years. Only for you, PHP, I did start
my Knode again. And I am very content with this communication channel. Also
I like the idea that one has a choice.
Anyways, OP was complaining about missing interfaces and features, which is
simply not true. You can communicate through Email, NNTP and if one wants a
webinterface so hardly just wrap one around NNTP. How can it be more
accessible by reducing it to some webinterface only?
Markus Malkusch
Anyways, OP was complaining about missing interfaces and features, which is
simply not true. You can communicate through Email, NNTP and if one wants a
webinterface so hardly just wrap one around NNTP. How can it be more
accessible by reducing it to some webinterface only?
Some of the web based forums have attempted to integrate email with the
on-line interface. Yahoo groups is an utter pain but I don't have to use
any of the web based interface, I just use emails and in the morning
there will be a number sitting in inbox so I don't have to scan around a
dozen sites to see what is happening. The ones that do send email
notifications make a half hearted attempt, but one has to go on line to
see the content o post replies. What IS needed is a nice cross format
system of working, but that only requires adding a preferred web
interface to the existing email service? Perhaps then people who seem to
prefer top posting will use the web interface and those of us who prefer
a private local archive will then simply get the new text ... as an email.
There are already web based interfaces but not providing what some
people seem to want. What is stopping the development of one of those
interfaces into an addition to the existing email channels? No need to
MOVE anything!
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Anyways, OP was complaining about missing interfaces and features, which is
simply not true. You can communicate through Email, NNTP and if one wants a
webinterface so hardly just wrap one around NNTP. How can it be more
accessible by reducing it to some webinterface only?
No one said that it would be a web interface only (though that is most
common). An email system could be supported.
I hate sounding like a hipster youngin', but there's a reason why web
interfaces have been replacing a lot of things over the years, though.
It seems like pretty much everything computerized can access a web
interface these days.
Some of the web based forums have attempted to integrate email with the
on-line interface. Yahoo groups is an utter pain but I don't have to use
any of the web based interface, I just use emails and in the morning
there will be a number sitting in inbox so I don't have to scan around a
dozen sites to see what is happening.
That does seem like a reasonable advantage to supporting email.
The ones that do send email
notifications make a half hearted attempt, but one has to go on line to
see the content o post replies. What IS needed is a nice cross format
system of working, but that only requires adding a preferred web
interface to the existing email service? Perhaps then people who seem to
prefer top posting will use the web interface and those of us who prefer
a private local archive will then simply get the new text ... as an email.
That sounds like a conflict of interest, but that's just me.
There are already web based interfaces but not providing what some
people seem to want. What is stopping the development of one of those
interfaces into an addition to the existing email channels? No need to
MOVE anything!
What is stopping development? NNTP is an ancient protocol. Nobody wants
to bother writing new software for it.
--
Stephen Coakley
Anyways, OP was complaining about missing interfaces and features,
which is
simply not true. You can communicate through Email, NNTP and if one
wants a
webinterface so hardly just wrap one around NNTP. How can it be more
accessible by reducing it to some webinterface only?No one said that it would be a web interface only (though that is most
common). An email system could be supported.
It's that 'could' which is the problem. A number of lists I am involved
with have moved off yahoo because 'the web interface is crap', but the
replacements still do not work email wise so half the users are still on
yahoo. Yet there IS no problem supporting email as yahoo proves, just
their shit upgrades to improve advertising revenue which are the problem
on the web interface.
I hate sounding like a hipster youngin', but there's a reason why web
interfaces have been replacing a lot of things over the years, though.
It seems like pretty much everything computerized can access a web
interface these days.
And I suppose you have 24/7 internet without interruptions everywhere
you go? I can't get a mobile signal many places I go, but I can still
read and work out replies off-line. I'm sure I'm not the only one?
Some of the web based forums have attempted to integrate email with the
on-line interface. Yahoo groups is an utter pain but I don't have to use
any of the web based interface, I just use emails and in the morning
there will be a number sitting in inbox so I don't have to scan around a
dozen sites to see what is happening.That does seem like a reasonable advantage to supporting email.
I can see all of the replies to this thread this morning even if the
line has dropped ... some lists I used to use I've now dropped simply
because their 'email summary' means I have to go on-line to see if any
of them actually have an interest. On the email lists I can see
everything that has happened over night ...
The ones that do send email
notifications make a half hearted attempt, but one has to go on line to
see the content o post replies. What IS needed is a nice cross format
system of working, but that only requires adding a preferred web
interface to the existing email service? Perhaps then people who seem to
prefer top posting will use the web interface and those of us who prefer
a private local archive will then simply get the new text ... as an
email.That sounds like a conflict of interest, but that's just me.
One of the complaints about the email list IS the 'one line replies top
posted', and yahoo has problems with people receiving the 'digest' and
replying via that quoting the whole thing. Personally I would prefer
that 'top posters' simply switched off ANY quoting since we don't need
yet another copy, and the web interface would hopefully provide that
avenue.
There are already web based interfaces but not providing what some
people seem to want. What is stopping the development of one of those
interfaces into an addition to the existing email channels? No need to
MOVE anything!What is stopping development? NNTP is an ancient protocol. Nobody wants
to bother writing new software for it.
I'm not talking about the news feed, that is just ANOTHER channel into
the archive and I see no reason to break that either. Just improve one
of the web based services to provided an additional 'edit' facility and
leave everything else in place as it is? What I am asking is what is
missing from the likes of
internals@lists.php.net/" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/ but I think
https://marc.info/?l=php-internals is open source code and the one
php.net refers to?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
You have to admit, NNTP news is an aging technology, with fewer and
fewer readers available as time goes on. Nowadays (for graphical
clients), there's Pan, and Thunderbird, and...? I use Thunderbird at the
moment, because I didn't want to fill up my email, and there aren't too
many readers. Heck, Thunderbird is technically a "discontinued" product.
... and with a forum there is only a single client. The forum
itself. ;-)
SCNR,
johannes
You have to admit, NNTP news is an aging technology, with fewer and
fewer readers available as time goes on. Nowadays (for graphical
clients), there's Pan, and Thunderbird, and...? I use Thunderbird at the
moment, because I didn't want to fill up my email, and there aren't too
many readers. Heck, Thunderbird is technically a "discontinued" product.... and with a forum there is only a single client. The forum
itself. ;-)SCNR,
johannes--
Redmine would be a good option. http://www.redmine.org/
The feature list has most everything covered in this thread.
http://www.redmine.org/projects/redmine/wiki/Features
On Tuesday, 4 August 2015, Johannes Schlüter johannes@schlueters.de
wrote:You have to admit, NNTP news is an aging technology, with fewer and
fewer readers available as time goes on. Nowadays (for graphical
clients), there's Pan, and Thunderbird, and...? I use Thunderbird at
the
moment, because I didn't want to fill up my email, and there aren't too
many readers. Heck, Thunderbird is technically a "discontinued"
product.... and with a forum there is only a single client. The forum
itself. ;-)SCNR,
johannes--
Redmine would be a good option. http://www.redmine.org/
The feature list has most everything covered in this thread.
http://www.redmine.org/projects/redmine/wiki/Features--
hi,
maybe it just me, but it seems to me, that every time this idea is brought
up, not many people from the actual participants of the list speak up, but
bunch of people who never before sent a mail to the list will chip in.
I'm not saying that there is nothing to improve, but I think that it would
be important to actually incorporate some feedback from the people actually
generating the content on the list.
personally I would prefer moving to something like google groups and doing
in a way that we can preserve archives (
https://github.com/wojdyr/fityk/wiki/MigrationToGoogleGroups)
that would allow us to actually kill our ancient list/ezmlm infrastructure
along with news.php.net which would be a huge win.
it would also make it much more easier to search/link to our mailing lists
archives:
news.php.net has no way of searching, news://news.php.net is pretty slow,
we have a couple of mail archives like
internals@lists.php.net/" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/ which are indexing
some of our mailing lists, but they don't have the archives from the
beginings, but I remember seeing a mail from them to ask for our archives
in an mbox and they then would be able to add the missing indexes.
moving to google groups would also make it much easier to manage the groups
(there are less people familiar with ezmlm administration than people with
google groups experience) and make it easier to reply to old mails.
I think that would suit our usage pattern better than a forum and
personally I don't really want to start hosting/maintaining one (we should
have to integrate our own auth and probably acl into that, security audit,
keep it up-to-date, etc.).
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Tuesday, 4 August 2015, Johannes Schlüter johannes@schlueters.de
wrote:You have to admit, NNTP news is an aging technology, with fewer and
fewer readers available as time goes on. Nowadays (for graphical
clients), there's Pan, and Thunderbird, and...? I use Thunderbird at
the
moment, because I didn't want to fill up my email, and there aren't too
many readers. Heck, Thunderbird is technically a "discontinued"
product.... and with a forum there is only a single client. The forum
itself. ;-)SCNR,
johannes--
Redmine would be a good option. http://www.redmine.org/
The feature list has most everything covered in this thread.
http://www.redmine.org/projects/redmine/wiki/Features--
hi,
maybe it just me, but it seems to me, that every time this idea is brought
up, not many people from the actual participants of the list speak up, but
bunch of people who never before sent a mail to the list will chip in.
I'm not saying that there is nothing to improve, but I think that it would
be important to actually incorporate some feedback from the people actually
generating the content on the list.
personally I would prefer moving to something like google groups and doing
in a way that we can preserve archives (
https://github.com/wojdyr/fityk/wiki/MigrationToGoogleGroups)
that would allow us to actually kill our ancient list/ezmlm infrastructure
along with news.php.net which would be a huge win.
it would also make it much more easier to search/link to our mailing lists
archives:
news.php.net has no way of searching, news://news.php.net is pretty slow,
we have a couple of mail archives like
internals@lists.php.net/" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/ which are indexing
some of our mailing lists, but they don't have the archives from the
beginings, but I remember seeing a mail from them to ask for our archives
in an mbox and they then would be able to add the missing indexes.
moving to google groups would also make it much easier to manage the groups
(there are less people familiar with ezmlm administration than people with
google groups experience) and make it easier to reply to old mails.I think that would suit our usage pattern better than a forum and
personally I don't really want to start hosting/maintaining one (we should
have to integrate our own auth and probably acl into that, security audit,
keep it up-to-date, etc.).--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
Not to pile in another voice from not a long-term participant, but
here's my unsolicited $0.02 on this matter:
Personally, I'd be fine with Google Groups. I recently set a few up
for internal discussions (mostly to coordinate future blog posts for
Paragon and brainstorm project ideas) and they're quite pleasant.
One question (open for everyone, I don't necessarily expect Ferenc to know):
Can we still archive messages on third-party sites (e.g.
gmane.org/marc.info)? I've not delved into integration yet.
Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises <https://paragonie.com
On Tue, Aug 4, 2015 at 7:18 PM, Scott Arciszewski scott@paragonie.com
wrote:
On Tuesday, 4 August 2015, Johannes Schlüter johannes@schlueters.de
wrote:You have to admit, NNTP news is an aging technology, with fewer and
fewer readers available as time goes on. Nowadays (for graphical
clients), there's Pan, and Thunderbird, and...? I use Thunderbird at
the
moment, because I didn't want to fill up my email, and there aren't
too
many readers. Heck, Thunderbird is technically a "discontinued"
product.... and with a forum there is only a single client. The forum
itself. ;-)SCNR,
johannes--
Redmine would be a good option. http://www.redmine.org/
The feature list has most everything covered in this thread.
http://www.redmine.org/projects/redmine/wiki/Features--
hi,
maybe it just me, but it seems to me, that every time this idea is
brought
up, not many people from the actual participants of the list speak up,
but
bunch of people who never before sent a mail to the list will chip in.
I'm not saying that there is nothing to improve, but I think that it
would
be important to actually incorporate some feedback from the people
actually
generating the content on the list.
personally I would prefer moving to something like google groups and
doing
in a way that we can preserve archives (
https://github.com/wojdyr/fityk/wiki/MigrationToGoogleGroups)
that would allow us to actually kill our ancient list/ezmlm
infrastructure
along with news.php.net which would be a huge win.
it would also make it much more easier to search/link to our mailing
lists
archives:
news.php.net has no way of searching, news://news.php.net is pretty
slow,
we have a couple of mail archives like
internals@lists.php.net/" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/ which are indexing
some of our mailing lists, but they don't have the archives from the
beginings, but I remember seeing a mail from them to ask for our archives
in an mbox and they then would be able to add the missing indexes.
moving to google groups would also make it much easier to manage the
groups
(there are less people familiar with ezmlm administration than people
with
google groups experience) and make it easier to reply to old mails.I think that would suit our usage pattern better than a forum and
personally I don't really want to start hosting/maintaining one (we
should
have to integrate our own auth and probably acl into that, security
audit,
keep it up-to-date, etc.).--
Ferenc Kovács
@Tyr43l - http://tyrael.huNot to pile in another voice from not a long-term participant, but
here's my unsolicited $0.02 on this matter:Personally, I'd be fine with Google Groups. I recently set a few up
for internal discussions (mostly to coordinate future blog posts for
Paragon and brainstorm project ideas) and they're quite pleasant.One question (open for everyone, I don't necessarily expect Ferenc to
know):
Can we still archive messages on third-party sites (e.g.
gmane.org/marc.info)? I've not delved into integration yet.Scott Arciszewski
Chief Development Officer
Paragon Initiative Enterprises https://paragonie.com
it is possible and there is preference for it:
http://article.gmane.org/gmane.discuss/16642
http://www.ossec.net/?page_id=21
--
Ferenc Kovács
@Tyr43l - http://tyrael.hu
On Tue, Aug 4, 2015 at 7:18 PM, Scott Arciszewski scott@paragonie.com
wrote:On Tuesday, 4 August 2015, Johannes Schlüter johannes@schlueters.de
wrote:You have to admit, NNTP news is an aging technology, with
fewer and fewer readers available as time goes on. Nowadays
(for graphical clients), there's Pan, and Thunderbird,
and...? I use Thunderbird at the moment, because I didn't
want to fill up my email, and there aren't too many readers.
Heck, Thunderbird is technically a "discontinued" product.... and with a forum there is only a single client. The forum
itself. ;-)
Yes, and a forum is "oh let me see whether there is a new post" compared
to: here is a new post. A mailinglist also allows for filters, searches,
etc, a forum never does. And most of their interfaces for editting text
are even worse than Gmail.
Redmine would be a good option. http://www.redmine.org/
The feature list has most everything covered in this thread.
http://www.redmine.org/projects/redmine/wiki/Featuresmaybe it just me, but it seems to me, that every time this idea is
brought up, not many people from the actual participants of the
list speak up, but bunch of people who never before sent a mail to
the list will chip in.
Right, because most of us, are likely just happy with what there
currently exists.
I'm not saying that there is nothing to improve, but I think that
it would be important to actually incorporate some feedback from
the people actually generating the content on the list. personally
I would prefer moving to something like google groups and doing in
a way that we can preserve archives (
https://github.com/wojdyr/fityk/wiki/MigrationToGoogleGroups) that
would allow us to actually kill our ancient list/ezmlm
infrastructure along with news.php.net which would be a huge win.
GoogleGroups? You must be kidding. It's a pile of poo. Not only is it
ridiculously bad in following any sort of RFC (quoting breakage,
in-reply-to errors, and mangling), it also promotes bad
multiple-people-discussions, such as top-posting. Then, it routes mail
wrong sometimes, and good luck managing a list with it.
it would also make it much more easier to search/link to our
mailing lists archives: news.php.net has no way of searching,
news://news.php.net is pretty slow, we have a couple of mail
archives like
internals@lists.php.net/" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/ which are
indexing some of our mailing lists, but they don't have the
archives from the beginings, but I remember seeing a mail from
them to ask for our archives in an mbox and they then would be
able to add the missing indexes.
That was Gmane, which has all 100055+ emails archived. It's also an NNTP
server that allows everybody to read and write to the list:
http://dir.gmane.org/gmane.comp.php.devel
moving to google groups would
also make it much easier to manage the groups (there are less
people familiar with ezmlm administration than people with google
groups experience) and make it easier to reply to old mails.
ezmlm isn't that hard to manage, it's just that we don't have enough
people to do it - are you volunteering?
I think that would suit our usage pattern better than a forum and
personally I don't really want to start hosting/maintaining one
(we should have to integrate our own auth and probably acl into
that, security audit, keep it up-to-date, etc.).
Well, I think Google Groups is shit :)
cheers,
Derick
On Tuesday, 4 August 2015, Johannes Schlüter johannes@schlueters.de
wrote:You have to admit, NNTP news is an aging technology, with fewer and
fewer readers available as time goes on. Nowadays (for graphical
clients), there's Pan, and Thunderbird, and...? I use Thunderbird at
the
moment, because I didn't want to fill up my email, and there aren't too
many readers. Heck, Thunderbird is technically a "discontinued"
product.... and with a forum there is only a single client. The forum
itself. ;-)SCNR,
johannes--
Redmine would be a good option. http://www.redmine.org/
The feature list has most everything covered in this thread.
http://www.redmine.org/projects/redmine/wiki/Features--
hi,
maybe it just me, but it seems to me, that every time this idea is brought
up, not many people from the actual participants of the list speak up, but
bunch of people who never before sent a mail to the list will chip in.
I'm not saying that there is nothing to improve, but I think that it would
be important to actually incorporate some feedback from the people actually
generating the content on the list.
What can we do to ask feedback on the issue from those people? I really
want to hear what they think too.
personally I would prefer moving to something like google groups and doing
in a way that we can preserve archives (
https://github.com/wojdyr/fityk/wiki/MigrationToGoogleGroups)
that would allow us to actually kill our ancient list/ezmlm infrastructure
along with news.php.net which would be a huge win.
it would also make it much more easier to search/link to our mailing lists
archives:
news.php.net has no way of searching, news://news.php.net is pretty slow,
we have a couple of mail archives like
internals@lists.php.net/" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/ which are indexing
some of our mailing lists, but they don't have the archives from the
beginings, but I remember seeing a mail from them to ask for our archives
in an mbox and they then would be able to add the missing indexes.
moving to google groups would also make it much easier to manage the groups
(there are less people familiar with ezmlm administration than people with
google groups experience) and make it easier to reply to old mails.I think that would suit our usage pattern better than a forum and
personally I don't really want to start hosting/maintaining one (we should
have to integrate our own auth and probably acl into that, security audit,
keep it up-to-date, etc.).
I mean really, that would work too and I would be happy with that. That
offers several advantages as well to the mailing list system. The main
problem is convincing the group to adopt a platform that is different
than the current one.
--
Stephen Coakley
maybe it just me, but it seems to me, that every time this idea is
brought
up, not many people from the actual participants of the list speak up,
but
bunch of people who never before sent a mail to the list will chip in.
I'm not saying that there is nothing to improve, but I think that it
would
be important to actually incorporate some feedback from the people
actually
generating the content on the list.What can we do to ask feedback on the issue from those people? I really
want to hear what they think too.
If in doubt, create an RFC, see https://wiki.php.net/rfc/howto on how
to do so.
--
Christoph M. Becker
personally I would prefer moving to something like google groups and doing
in a way that we can preserve archives (
I have no experience with google groups in a day o day usage basis. So
I can't judge what they might do better. But a fun fact: PHP was started
in 1995, Google only in 1998. Since 1995 many services and companies
came and left. I don't think it is wise to make our processes depend on
an external organization for which doesn't care about us. See i.e.
GitHub. It s nice that folks can easily contribute code there but even
if GitHub decides to shut down tomorrow it wouldn't have any impact on
us, which is good.
This mailing list is the heart of the php.net processes. So we should be
in control.
Yes, our own interfaces for outsiders aren't thaaaat nice. I remember
Kalle(?) was working on a newer news.php.net web interface. Not sure
what the state about that is. I believe that if the time used in this
discussion had been used to modernize news.php.net it would have been a
bigger benefit.
Finally a quick word about tools like Redmine, Jira etc. Those are nice
to formalize and enforce a structure and a process, but they work on
another premise than our project: Simplified they assume a corporate
environment where you plan your work and then assign your (human)
resources to items (yes, yes, way more "agile"! I know) but that's not
the environment we're having here: We can't reliably plan. Here
contributors can disappear any time and they do that. And at some point
they might find the time again and drop patches/proposals. And I think
it is important to keep this open process. While there's room for fine
tuning it, our RFC process does a good thing in documenting those drops
while making sure that PHP can be a fun project, not one which feels
like work.
And I think it's incredible how little our entry barrier is. This
enabled us that most features post 5.3 where added by folks who haven't
been contributed before 5.3. It's really great to see all the new names
which appeared in the NEWS file! And even RMs. A few o the recent RMs
aren't long in the project either. And that in a project which isn't in
a small corner but which is a central piece of the Web. A wrong decision
here and tons of sites have issues. Tons of developers have to change
their code. I'm always fascinated about that. (also looking back at my
"PHP career" from that young kid who writes a small stupid patch nobody
would seriously consider to RM to conservative elder on the outside
complaining about all those patches nobody would consider by all these
young kids :-D)
Now back to other things,
johannes
Redmine would be a good option. http://www.redmine.org/
The feature list has most everything covered in this thread.
http://www.redmine.org/projects/redmine/wiki/Features
Feature list is nice, but is PHP really unable to provide a similar service?
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Redmine would be a good option. http://www.redmine.org/
The feature list has most everything covered in this thread.
http://www.redmine.org/projects/redmine/wiki/FeaturesFeature list is nice, but is PHP really unable to provide a similar service?
I think anyone suggesting Redmine is trolling this list.
The question was about forum software and Redmine has no specific forum support. And if you wanted a dev tracker tool, which Redmine is, Phabricator is obviously superior and more modern than Redmine which is just a Trac clone. Phabricator is opinionated about process, which is a barrier for those who prefer existing processes. But neither really address what this thread is about.
--
Lester Caine - G8HFLContact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk--
Tom
We're discussing issues here, so what's wrong with an issue tracker?
No, we're discussing every aspect of the project, from release management to personal introductions.
I can see more than one benefit. Probably most important is that you
can
follow just some things, instead of getting all the mails.
I subscribe with a gmail account, filter the list into its own folder, then pick out the threads I'm interested in using Thunderbird or K9 Mail. Most of the time there are only about half a dozen active threads anyway.
Additionally, you
can ping people, that's not possible here, most mails are just "reply
all"
messages.
I CC'd you on this message; how is that not "pinging' you? Actually, it's a bit too easy, as a lot of the time "Reply to All" is simpler than "Reply to List". Either way, that's a feature issue trackers have borrowed from forums rather than vice versa.
Regards,
Rowan Collins
[IMSoP]
2015-08-02 15:29 GMT+02:00 Rowan Collins rowan.collins@gmail.com:
We're discussing issues here, so what's wrong with an issue tracker?
No, we're discussing every aspect of the project, from release management
to personal introductions.
Release management, RFCs and other things totally fit something I'd call
issue.
Personal introductions are a valid point, they're nothing I'd do with
issues, that's something that fits here.
I can see more than one benefit. Probably most important is that you
can
follow just some things, instead of getting all the mails.I subscribe with a gmail account, filter the list into its own folder,
then pick out the threads I'm interested in using Thunderbird or K9 Mail.
Most of the time there are only about half a dozen active threads anyway.Additionally, you
can ping people, that's not possible here, most mails are just "reply
all"
messages.I CC'd you on this message; how is that not "pinging' you? Actually, it's
a bit too easy, as a lot of the time "Reply to All" is simpler than
"Reply to List". Either way, that's a feature issue trackers have borrowed
from forums rather than vice versa.
It's probably because GMail lacks a clear indication here. There is one,
but not eye-catching enough.
Having a lot of clients to choose from with different features can totally
be a advantage, because everyone can choose the one that he / she likes
best, but there are also disadvantages like a higher barrier for new users
or non-regular users.
TBH, it's not just about communication on the mailing list here. PHP's bug
tracker is a real PITA, at least for users without a php.net account.
How about a tool like Phabricator?
Regards, Niklas
Regards,
Rowan Collins
[IMSoP]
2015-08-02 15:29 GMT+02:00 Rowan Collins rowan.collins@gmail.com:
We're discussing issues here, so what's wrong with an issue tracker?
No, we're discussing every aspect of the project, from release
management
to personal introductions.Release management, RFCs and other things totally fit something I'd
call
issue.
See one of my other replies for more categories of content, which don't feel like a good fit for issues, which in my mind is for finite work flows like raise-discuss-assign-close...
Personal introductions are a valid point, they're nothing I'd do with
issues, that's something that fits here.
[...]
TBH, it's not just about communication on the mailing list here. PHP's
bug
tracker is a real PITA, at least for users without a php.net account.
So perhaps rather than replacing Internals, it's a question of finding a nicer issue tracker (fuller featured than either GitHub or bugs.php.net), making better use of it, and defining what things should be in it and what should stay in a more open discussion forum like this list?
Hi Niklas
Am 02.08.2015 um 16:26 schrieb Niklas Keller me@kelunik.com:
2015-08-02 15:29 GMT+02:00 Rowan Collins rowan.collins@gmail.com:
We're discussing issues here, so what's wrong with an issue tracker?
No, we're discussing every aspect of the project, from release management
to personal introductions.Release management, RFCs and other things totally fit something I'd call
issue.
Personal introductions are a valid point, they're nothing I'd do with
issues, that's something that fits here.I can see more than one benefit. Probably most important is that you
can
follow just some things, instead of getting all the mails.I subscribe with a gmail account, filter the list into its own folder,
then pick out the threads I'm interested in using Thunderbird or K9 Mail.
Most of the time there are only about half a dozen active threads anyway.Additionally, you
can ping people, that's not possible here, most mails are just "reply
all"
messages.I CC'd you on this message; how is that not "pinging' you? Actually, it's
a bit too easy, as a lot of the time "Reply to All" is simpler than
"Reply to List". Either way, that's a feature issue trackers have borrowed
from forums rather than vice versa.It's probably because GMail lacks a clear indication here. There is one,
but not eye-catching enough.
Having a lot of clients to choose from with different features can totally
be a advantage, because everyone can choose the one that he / she likes
best, but there are also disadvantages like a higher barrier for new users
or non-regular users.
So basically we shall change a well established open source tool because gmail isn't capable of handling an RFC and Some developers are unable to setup their tools properly? Yes it is exagerating I know. But that' how I currently feel about this topic.
TBH, it's not just about communication on the mailing list here. PHP's bug
tracker is a real PITA, at least for users without a php.net account.
I'm not sure why it's a PITA. you can search for issues without problems. And if you miss certain functions you can open a PR. Yes, without karma you can't change anything. Which - AFAIK - isn't possible in github or any other issue-tracker as well. And that's what we are talking about here.
How about a tool like Phabricator?
And why not Jira? Or bugzilla? Or Bitbucket? Or gitlab? or github? or ...
Why not use the existing tools and spend the time lost in such discussions by instead making these tools awesome?
Cheers
Andreas
2015-08-02 16:48 GMT+02:00 Andreas Heigl andreas@heigl.org:
Hi Niklas
Am 02.08.2015 um 16:26 schrieb Niklas Keller me@kelunik.com:
2015-08-02 15:29 GMT+02:00 Rowan Collins rowan.collins@gmail.com:
We're discussing issues here, so what's wrong with an issue tracker?
No, we're discussing every aspect of the project, from release
management
to personal introductions.Release management, RFCs and other things totally fit something I'd call
issue.
Personal introductions are a valid point, they're nothing I'd do with
issues, that's something that fits here.I can see more than one benefit. Probably most important is that you
can
follow just some things, instead of getting all the mails.I subscribe with a gmail account, filter the list into its own folder,
then pick out the threads I'm interested in using Thunderbird or K9
Mail.
Most of the time there are only about half a dozen active threads
anyway.Additionally, you
can ping people, that's not possible here, most mails are just "reply
all"
messages.I CC'd you on this message; how is that not "pinging' you? Actually,
it's
a bit too easy, as a lot of the time "Reply to All" is simpler than
"Reply to List". Either way, that's a feature issue trackers have
borrowed
from forums rather than vice versa.It's probably because GMail lacks a clear indication here. There is one,
but not eye-catching enough.
Having a lot of clients to choose from with different features can
totally
be a advantage, because everyone can choose the one that he / she likes
best, but there are also disadvantages like a higher barrier for new
users
or non-regular users.So basically we shall change a well established open source tool because
gmail isn't capable of handling an RFC and Some developers are unable to
setup their tools properly? Yes it is exagerating I know. But that' how I
currently feel about this topic.
I can see your point. I just think open source projects shouldn't have the
need to setup a bunch of tools to contribute in a discussion.
TBH, it's not just about communication on the mailing list here. PHP's
bug
tracker is a real PITA, at least for users without a php.net account.I'm not sure why it's a PITA. you can search for issues without problems.
And if you miss certain functions you can open a PR. Yes, without karma you
can't change anything. Which - AFAIK - isn't possible in github or any
other issue-tracker as well. And that's what we are talking about here.
Not being able to change anything without karma is totally fine, PRs are a
good and established way here. Problem is more that if you want to discuss
things here, you'd have to setup the tools you were talking about, just to
follow a single discussion.
How about a tool like Phabricator?
And why not Jira? Or bugzilla? Or Bitbucket? Or gitlab? or github? or ...
All of them would be better than the current PHP bug tracker, Phabricator
was just an example for a open tool better than the current system. Hey,
there isn't even a login for users without php.net account.
Why not use the existing tools and spend the time lost in such discussions
by instead making these tools awesome?
Yeah, good question, why was php-bugs created again?
Regards, Niklas
Cheers
Andreas
Am 02.08.2015 um 17:12 schrieb Niklas Keller me@kelunik.com:
2015-08-02 16:48 GMT+02:00 Andreas Heigl andreas@heigl.org:
Hi Niklas
Am 02.08.2015 um 16:26 schrieb Niklas Keller me@kelunik.com:
2015-08-02 15:29 GMT+02:00 Rowan Collins rowan.collins@gmail.com:
We're discussing issues here, so what's wrong with an issue tracker?
No, we're discussing every aspect of the project, from release
management
to personal introductions.Release management, RFCs and other things totally fit something I'd call
issue.
Personal introductions are a valid point, they're nothing I'd do with
issues, that's something that fits here.I can see more than one benefit. Probably most important is that you
can
follow just some things, instead of getting all the mails.I subscribe with a gmail account, filter the list into its own folder,
then pick out the threads I'm interested in using Thunderbird or K9
Mail.
Most of the time there are only about half a dozen active threads
anyway.Additionally, you
can ping people, that's not possible here, most mails are just "reply
all"
messages.I CC'd you on this message; how is that not "pinging' you? Actually,
it's
a bit too easy, as a lot of the time "Reply to All" is simpler than
"Reply to List". Either way, that's a feature issue trackers have
borrowed
from forums rather than vice versa.It's probably because GMail lacks a clear indication here. There is one,
but not eye-catching enough.
Having a lot of clients to choose from with different features can
totally
be a advantage, because everyone can choose the one that he / she likes
best, but there are also disadvantages like a higher barrier for new
users
or non-regular users.So basically we shall change a well established open source tool because
gmail isn't capable of handling an RFC and Some developers are unable to
setup their tools properly? Yes it is exagerating I know. But that' how I
currently feel about this topic.I can see your point. I just think open source projects shouldn't have the
need to setup a bunch of tools to contribute in a discussion.TBH, it's not just about communication on the mailing list here. PHP's
bug
tracker is a real PITA, at least for users without a php.net account.I'm not sure why it's a PITA. you can search for issues without problems.
And if you miss certain functions you can open a PR. Yes, without karma you
can't change anything. Which - AFAIK - isn't possible in github or any
other issue-tracker as well. And that's what we are talking about here.Not being able to change anything without karma is totally fine, PRs are a
good and established way here. Problem is more that if you want to discuss
things here, you'd have to setup the tools you were talking about, just to
follow a single discussion.
You can open a PR on github and do your conversation on that PR on github. On PHP.net the PR is added to the issue. So you already can have PRs and discussion on them on bugs.php.net. And you can also register yourself to track an issue on the bugtracker and get informed of all future changes and comments. So you can comment on the Issue AND on the PR. All currently possible. Yes, the "follow an issue" could be somewhat easier to setup. Feel free to open a PR against the bugtracker.
Perhaps we need a place to describe what's already possible with the currently available tools and describe how to more easily get setup for internals. Or link the already existing resources together and display them more prominent and self-confident.
I won't be able to do anything like that in the next 2 weeks but can think about it afterwards. Not that I think I'm the right person for the job but I hate that "someone should do something"...
So ball is in play!
How about a tool like Phabricator?
And why not Jira? Or bugzilla? Or Bitbucket? Or gitlab? or github? or ...
All of them would be better than the current PHP bug tracker, Phabricator
was just an example for a open tool better than the current system. Hey,
there isn't even a login for users without php.net account.Why not use the existing tools and spend the time lost in such discussions
by instead making these tools awesome?Yeah, good question, why was php-bugs created again?
Because when it was created in 2001 nothing else existed (written in PHP at least).
Cheers
Andreas
How about a tool like Phabricator?
I've never used Phabricator, but it does look like a nice project management tool. I first heard of it in reference to Wikimedia migrating a whole bunch of teams to it as a unified tool. However, it's perhaps relevant to note that I can see nothing in their migration plans that implies the mediawiki-l and wikitech-l mailing lists will be retired, suggesting that they still see a use for good old-fashioned e-mail groups.
I think part of the problem with concentrating on how easy it is to filter down to specific tasks is that what new users actually need is the opposite: an overview of what's going on, and a place where broad topics won't be closed as an Invalid Task. That then serves as an entry into more specific task-based activity.
If every thread on PHP Internals was converted to a tree of linked Issues in a database of thousands of threads, how would you know where to begin?
And how would busy core devs avoid missing an important discussion happening on an Issue which mutates from a user's bug report to a breaking change in the language? I'm not saying what we have now is perfect for that, but a post to Internals can draw attention to the one bug in hundreds where that has happened, and allow the wider issue to be discussed separately from the line-by-line code review of a patch.
Regards,
Rowan Collins
[IMSoP]
We're discussing issues here, so what's wrong with an issue tracker?
No, we're discussing every aspect of the project, from release management to personal introductions.
I agree with this, and that's why the GitHub issue tracker doesn't make
much sense as a mailing list alternative. Not that I'm against the
GitHub issue tracker -- it would serve better as a replacement to
http://bugs.php.net, which is a different discussion (and there's not
really anything wrong with the current bug tracker).
A forum is the correct alternative to a mailing list, if we were looking
for an alternative.
--
Stephen Coakley
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).
While I think a different medium could be worth considering, I don't think squeezing open-ended discussions into an issue management system is a good idea. I don't think the archives would be any easier to use, and a lot of conversations don't need elaborate code references. Those that do can use Pull Requests etc on GitHub already, and we could think of ways of making those more visible without generating excessive noise on the main list.
There's always a temptation to put everything in one place, but it generally means compromises in the tools used. For instance, Wikipedia and MediaWiki use wiki pages for discussion, and Stack Overflow uses Q&A pages, but neither works as well as something actually designed for threaded discussion.
E-mail has the obvious advantage of being usable in many different ways by different people. With a decent threaded mail client (i.e. not GMail's web UI, whose "conversations" have no notion of sub-threads or marking some messages as read but not others), it's quite easy to pick out the subjects you're interested in, catch up after a while away, etc. There may be better archive interfaces out there, as I agree that those aren't great right now.
If you still think mailing lists aren't fit for purpose, though, why not look at something built for that actual purpose - phpBB, for instance?
As a final note, while encouraging new users is definitely a good thing, any project the size of PHP will always have a core set of developers who spend a lot of time working on and discussing it. If you make those people's lives difficult, no amount of shiny markdown is going to recover their lost effort, so any process change has to be carefully considered from that angle.
Regards,
Rowan Collins
[IMSoP]
As a final note, while encouraging new users is definitely a good thing, any project the size of PHP will always have a core set of developers who spend a lot of time working on and discussing it. If you make those people's lives difficult, no amount of shiny markdown is going to recover their lost effort, so any process change has to be carefully considered from that angle.
My own mail archive of this list goes back to 2004 although I have
previous messages in a less searchable format. What messes up that
archive is mainly the poor quality of quoting resulting in substantial
dross from the likes of top posters quoting all the previous sigs, but I
strip those messages and am left with a nice historic record of
developments.
internals@lists.php.net/msg79689.html" rel="nofollow" target="_blank">https://www.mail-archive.com/internals@lists.php.net/msg79689.html
provides a nice searchable version of the original raw messages and yes
news://news.php.net/ provides a downloadable set of older material.
The mechanism itself is not broken, only the less than ideal following
of the guidelines in using it. NONE of the 'on-line' alternatives still
provide as good an alternative for on and off line working! So until the
whole world has perfect 100% available high speed internet ...
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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).While I think a different medium could be worth considering, I don't think squeezing open-ended discussions into an issue management system is a good idea. I don't think the archives would be any easier to use, and a lot of conversations don't need elaborate code references. Those that do can use Pull Requests etc on GitHub already, and we could think of ways of making those more visible without generating excessive noise on the main list.
There's always a temptation to put everything in one place, but it generally means compromises in the tools used. For instance, Wikipedia and MediaWiki use wiki pages for discussion, and Stack Overflow uses Q&A pages, but neither works as well as something actually designed for threaded discussion.
E-mail has the obvious advantage of being usable in many different ways by different people. With a decent threaded mail client (i.e. not GMail's web UI, whose "conversations" have no notion of sub-threads or marking some messages as read but not others), it's quite easy to pick out the subjects you're interested in, catch up after a while away, etc. There may be better archive interfaces out there, as I agree that those aren't great right now.
If you still think mailing lists aren't fit for purpose, though, why not look at something built for that actual purpose - phpBB, for instance?
As a final note, while encouraging new users is definitely a good thing, any project the size of PHP will always have a core set of developers who spend a lot of time working on and discussing it. If you make those people's lives difficult, no amount of shiny markdown is going to recover their lost effort, so any process change has to be carefully considered from that angle.
Regards,
+1. Forums were designed for the specific purpose of threaded
discussions. I personally am all for switching to a forum system, but I
know that replacing the mailing list is somewhat controversial.
P.S. I'm really excited for what Flarum http://flarum.org will bring
when its released. I'd recommend waiting to use Flarum if we were to set
up a forum. Of course, it's just my preference.
--
Stephen Coakley
Hi Dor.
Am 02.08.2015 um 14:01 schrieb 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)
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)?
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.
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.
Cheers
Andreas
Andreas Heigl
andreas@heigl.org
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.
Nothing arrogant about the comment ... what is more of a problem is the
SOB's who keep changing how those well established tools work :(
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
Hi Dor.
Am 02.08.2015 um 14:01 schrieb 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)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.
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.
I'm not sure what number you're quoting there, but in case you've missed
references in passing, PHP does have a presence on GitHub:
https://github.com/php/php-src That repo (which is a mirror of the
official self-hosted git repo) has apparently been forked over two
thousand times, and has 223 open and 1224 closed Pull Requests.
I don't know how to quantify the number of people using bugs.php.net,
but it has a stats page which suggests it's not exactly quiet:
https://bugs.php.net/stats.php (if you're superstitious, you may take it
as an omen that the Dupe count is currently 666...)
My local copy of about 2 years of internals posts suggests, in a very
unscientific way (counting the number of pages I have to scroll down
when grouping messages by sender), that as many as 600 different senders
have contributed to the list in that time. I have no idea what this
proves, but I also have no idea what your 400 refers to.
So, other than your own dislike of e-mails, what makes you think that a
large number of potential contributors are put off contributing to PHP
by using a mailing list for policy discussions?
Regards,
--
Rowan Collins
[IMSoP]
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.
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.
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-langFor 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.
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)?
For one: He can. He can submit a pull request via github or FR in
bugs.php.net. He can also send a mail to internals@ without subscribing.
due to "Reply-to-all" he will be part of the discussion around it. But
we want active contributors with an interest in the system. A
programming language isn't developed by looking at items in separation
but things interact with each other (yes, adding a library function here
or there to PHP can be looked at in some isolation, most things however
not)
johannes
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
That's interesting. Do you have a link to any documentation on the
process they use? For instance, how does the RFC gain final approval /
rejection?
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/
Right, so just as I mentioned phpBB earlier, they've set up a discussion
forum. It's not a piece of software I'm familiar with, so I can't speak
for its pros and cons vs a mailing list (apart from a personal dislike
of Infinite Scroll in place of pagination).
This is what I think. The best way to deter the community from making
contributions is to make it hard to contribute.
Agreed.
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.
You can do this with PHP as well - Pull Requests are accepted on GitHub.
I gather there is a bit of an issue with back log right now, and
suggestions for improving that are welcome.
Everyone were helpful and to the
point.
That's good to hear. Completely unrelated to the tools used, however.
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,
I remember it being pretty trivial - enter my e-mail address, verify my
e-mail address, skim-read the etiquette doc, start discussing.
only to
be in the discussion (often completely irrelevant to what he's trying to
do) for several weeks or months
If you're not interested in a particular discussion thread, don't read
and respond to it. Even GMail's subject-based "conversations" (which,
you may have gathered, I dislike) are perfectly adequate for that purpose.
On other other hand, if you want to become part of any community, it
pays to get a feel for what's going on and the general mood. Again, the
need for this is largely unrelated to the tools used; and if everything
was fractured into a thousand Issue threads, this would probably be
harder, not easier.
, 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)?
OK, so now we're talking about something completely different again -
not bugs, or patches for minor enhancements, but major changes to the
language or core functionality. Yes, there is a somewhat bureaucratic
process for these, in part because the lack of nominated project leaders
means some way of achieving and measuring consensus is required.
The need for wiki karma is sort of annoying, although it's given out
fairly readily from what I can see. It's a fancy word for "you need a
login to this tool, because we don't want it filling up with complete
spam", but maybe it could be stream-lined further. Nothing to do with
whether we use a mailing list as the main forum though.
If you want to improve the RFC process itself, that's a whole different
topic. That might mean more collaboration on the wiki itself, a better
process for summarising points raised so far, etc. If anything, RFCs
need a less conversation-like interface, not more, because currently
the discsussions tend to get rather repetitive on contentious issues.
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.
An oft-acknowledged fact.
And the way
you improve the atmosphere is to get more people, more eyes, more opinions.
Is it? I'm really not sure - if the problem is too many conflicting
opinions, then adding more people into the mix just makes things worse;
if the problem is too few people who really know and love the core, then
getting more contributors really actively involved would help...
Regards,
--
Rowan Collins
[IMSoP]
I remember it being pretty trivial - enter my e-mail address, verify my
e-mail address, skim-read the etiquette doc, start discussing.
I agree with that. Getting RFC karma isn't that hard, at least not if your
mail doesn't get lost during hot discussions.
If you're not interested in a particular discussion thread, don't read and
respond to it. Even GMail's subject-based "conversations" (which, you may
have gathered, I dislike) are perfectly adequate for that purpose.
Yeah, GMail even has "More > Ignore" to ignore whole threads.
Regards, Niklas
I remember it being pretty trivial - enter my e-mail address, verify my
e-mail address, skim-read the etiquette doc, start discussing.I agree with that. Getting RFC karma isn't that hard, at least not if your
mail doesn't get lost during hot discussions.
Also, getting karma/voting on RFCs/publishing a RFC is something completely different from taking part in the discussion - and from what I understood, that’s what OP claims is troublesome.
—Leszek
Hi
2015-08-02 16:52 GMT-03:00 Rowan Collins rowan.collins@gmail.com:
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-langThat's interesting. Do you have a link to any documentation on the process
they use?
You can see the process outlined here
https://github.com/rust-lang/rfcs#what-the-process-is.
For instance, how does the RFC gain final approval / rejection?
The biggest difference regarding "approval" is that we express
"consensus" by having a vote with 2/3 majority (voting makes sense
here because consensus by discussion rarely happens anyway).
On their side, they usually don't have a voting phase like we do, the
"consensus" is built rationally during the discussion phases. See the
list of RFCs in final phase
https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3Afinal-comment-period,
as an example.
Marcio
Hi
2015-08-02 16:52 GMT-03:00 Rowan Collins rowan.collins@gmail.com:
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-langThat's interesting. Do you have a link to any documentation on the process
they use?
You can see the process outlined here
https://github.com/rust-lang/rfcs#what-the-process-is.For instance, how does the RFC gain final approval / rejection?
The biggest difference regarding "approval" is that we express
"consensus" by having a vote with 2/3 majority (voting makes sense
here because consensus by discussion rarely happens anyway).On their side, they usually don't have a voting phase like we do, the
"consensus" is built rationally during the discussion phases. See the
list of RFCs in final phase
https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3Afinal-comment-period,
as an example.
Ah, interesting, thanks. :)
Actually, skimming that documentation, the key difference is not that
they magically attain consensus 100% of the time, but that they have a
nominated "core team" who make the final decision (via separate
channels, based on previous discussion), though all the links to who
they actually are appear to be dead links.
Interestingly, they also currently have an open RFC about scaling their
governance, including the RFC process itself:
https://github.com/aturon/rfcs/blob/rust-governance/text/0000-rust-governance.md
Regards,
--
Rowan Collins
[IMSoP]
Hi,
2015-08-02 17:46 GMT-03:00 Rowan Collins rowan.collins@gmail.com:
Hi
2015-08-02 16:52 GMT-03:00 Rowan Collins rowan.collins@gmail.com:
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
That's interesting. Do you have a link to any documentation on the
process
they use?You can see the process outlined here
https://github.com/rust-lang/rfcs#what-the-process-is.For instance, how does the RFC gain final approval / rejection?
The biggest difference regarding "approval" is that we express
"consensus" by having a vote with 2/3 majority (voting makes sense
here because consensus by discussion rarely happens anyway).On their side, they usually don't have a voting phase like we do, the
"consensus" is built rationally during the discussion phases. See the
list of RFCs in final phasehttps://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3Afinal-comment-period,
as an example.Ah, interesting, thanks. :)
Actually, skimming that documentation, the key difference is not that they
magically attain consensus 100% of the time, but that they have a nominated
"core team" who make the final decision (via separate channels, based on
previous discussion), though all the links to who they actually are appear
to be dead links.
Yes, that's supposed to happen in the "final-comment-period".
They do have a higher ratio of consensus though. But that's because
the language is still fresh, you have less technical debt, less BC
break issues to overcome, less design issues to fix (the language was
planned a lot) and other factors that might not be fruitful to bring
up here now.
Anyway, even with all the contextual differences, the useful lesson I
can take is that they are trying to find a way to get closer to their
community by not simply giving transparency, in a sub optimal way, and
then making claims like "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" or "just download a
newsreader and store the mails on your own database for further
research.".
They bothered to have transparency but also to wrap it in a more
appealing package. There are different generations of people and the
highly skilled ones that were born 40 years ago are not the same as
the ones born ~20 years ago and volunteering contributing today,
technology change.
This is their email announce the end of their mailing list back in
2015 https://mail.mozilla.org/pipermail/rust-dev/2015-January/011558.html
I'm not saying that we should do exactly the same thing. PHP is not
Rust. Rust is not PHP. But at least we could stop pretending our
process shouldn't be improved because the walls it offers supposedly
act as a filter for the one "who isn't able to get his tools set up
properly". This only shows a deep kind of ignorance on how FOOS works!
Interestingly, they also currently have an open RFC about scaling their
governance, including the RFC process itself:
https://github.com/aturon/rfcs/blob/rust-governance/text/0000-rust-governance.md
I missed this one. This is really cool, thanks for pointing it out.
Regards,
--
Rowan Collins
Thanks,
Marcio
I'm not saying that we should do exactly the same thing. PHP is not
Rust. Rust is not PHP. But at least we could stop pretending our
process shouldn't be improved because the walls it offers supposedly
act as a filter for the one "who isn't able to get his tools set up
properly". This only shows a deep kind of ignorance on how FOOS works!
Preach it!
Seriously though, I think we should be open to having a discussion about
replacing the mailing list for internals or for the entire news server.
If it doesn't happen, then, oh well. It's just a discussion system. On
the other hand, more modern tools pose more advantages than disadvantages.
I don't think GitHub issues is the right alternative, but I'm glad the
OP brought the discussion up anyway.
--
Stephen Coakley
--
Stephen Coakley
This is their email announce the end of their mailing list back in
2015
https://mail.mozilla.org/pipermail/rust-dev/2015-January/011558.html
Amusingly, the first reply to that is someone trying to set up an email gateway to the forum because they like their current workflow...
It's certainly worth considering a forum rather than e-mail if there's real evidence of advantages, though. The challenge then would be to figure out what to use - let's not pick something trendy and list "features" like infinite scroll and markdown, but actually think about what benefits of the ML we want to preserve, and what we want to fix.
So, for starters, we need something with a low barrier to entry, easy to keep track of what's new, with good search support, a decent threading and sub-threading system... I'm sure we could come up with a shopping list and evaluate systems against it.
Regards,
Rowan Collins
[IMSoP]
Am 03.08.2015 um 09:31 schrieb Rowan Collins rowan.collins@gmail.com:
This is their email announce the end of their mailing list back in
2015
https://mail.mozilla.org/pipermail/rust-dev/2015-January/011558.htmlAmusingly, the first reply to that is someone trying to set up an email gateway to the forum because they like their current workflow...
It's certainly worth considering a forum rather than e-mail if there's real evidence of advantages, though. The challenge then would be to figure out what to use - let's not pick something trendy and list "features" like infinite scroll and markdown, but actually think about what benefits of the ML we want to preserve, and what we want to fix.
So, for starters, we need something with a low barrier to entry, easy to keep track of what's new, with good search support, a decent threading and sub-threading system... I'm sure we could come up with a shopping list and evaluate systems against it.
First Items on the shopping List :
- push notification via Email ;)
- retrieval via news-protocol.
I (and I presume a lot of others) like to get the news delivered to my doorstep instead of having to pull the relevant information from a web-interface.
Cheers
Andreas
Regards,
Rowan Collins
[IMSoP]
This is their email announce the end of their mailing list back in
2015
https://mail.mozilla.org/pipermail/rust-dev/2015-January/011558.htmlAmusingly, the first reply to that is someone trying to set up an email gateway to the forum because they like their current workflow...
It's certainly worth considering a forum rather than e-mail if there's real evidence of advantages, though. The challenge then would be to figure out what to use - let's not pick something trendy and list "features" like infinite scroll and markdown, but actually think about what benefits of the ML we want to preserve, and what we want to fix.
So, for starters, we need something with a low barrier to entry, easy to keep track of what's new, with good search support, a decent threading and sub-threading system... I'm sure we could come up with a shopping list and evaluate systems against it.
Regards,
Hmm... there's also this: https://github.com/arkanis/nntp-forum. Not
sure how much cleanup it would need or what it even looks like. A forum
interface to the NNTP server. That would make everyone happy... except
for the people who want to avoid dual interfaces (I think I've heard
this before...)
--
Stephen Coakley
Hi, Rowan
2015-08-03 4:31 GMT-03:00 Rowan Collins rowan.collins@gmail.com:
This is their email announce the end of their mailing list back in
2015
https://mail.mozilla.org/pipermail/rust-dev/2015-January/011558.htmlAmusingly, the first reply to that is someone trying to set up an email gateway to the forum because they like their current workflow...
It's certainly worth considering a forum rather than e-mail if there's real evidence of advantages, though. The challenge then would be to figure out what to use - let's not pick something trendy and list "features" like infinite scroll and markdown, but actually think about what benefits of the ML we want to preserve, and what we want to fix.
So, for starters, we need something with a low barrier to entry, easy to keep track of what's new, with good search support, a decent threading and sub-threading system... I'm sure we could come up with a shopping list and evaluate systems against it.
Regards,
Rowan Collins
[IMSoP]--
It took a while to reply, I was doing a few experiments with the
Discourse platform:
So I subscribed to the Rust forum (https://internals.rust-lang.org/)
using the "login with github" option and waited a few days of usage to
see how good it is.
On the first day, I noticed that by default Discourse will not send
you a lot of emails so I wondered if we could get the same email
experience that we usually get from a regular mailing list, and turns
out it's possible. On the profile page these options can be marked:
https://dl.dropboxusercontent.com/u/49549530/screenshots/options.png
With that settings I've got an email entry for every reply on every
thread of the forum. The messages come in the following format along
with the replies if they exist:
https://dl.dropboxusercontent.com/u/49549530/screenshots/message.png
With just a few clicks it kinda works as a mailing list too + I could
enjoy all the benefits of the web UI :) The only thing I couldn't
adapt through the profile settings was the infinite scrolling, which I
don't love too.
I won't give any conclusion yet, but it's been very pleasurable to use
Discourse.
Marcio.
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
I already have. iojs (and soon, nodejs), as well as Rust which was
mentioned by someone else.
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
filesand 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
manytimes 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
I already have. iojs (and soon, nodejs), as well as Rust which was
mentioned by someone else.Are you being serious? Can you provide examples of projects that have
successfully replaced their developer mailing lists with GitHub issues?
The problems you refer to are fairly minor IMHO (searching archives,
finding the mailing list). Any developer worth his or her salt should be
able to figure that out.
But seriously: the core of your concerns are fixable with a proper mailing
list archive search engine.
Why do you think the PHP project has a full archive of all of the community
discussions back to the nineties? It's certainly not because we went all-in
with SourceForge back in its glory days. Rather, it's because we stuck with
open standards and mediums; good simple old email.
Don't get me wrong, I'm a happy paying GitHub customer, but it's not the
right tool for the job of community discussions at large, IMHO.
Now, if you started to talk about the RFC process or even PHP's bugtracker,
at least the solutions provided by GitHub would be in the right domain, but
that's a completely different topic.
- Stig
Are you being serious? Can you provide examples of projects that have
successfully replaced their developer mailing lists with GitHub issues?
I already have. iojs (and soon, nodejs), as well as Rust which was
mentioned by someone else.
I don't know about io/node, but Rust most certainly have not replaced a
mailing list with the issue tracker; they've replaced it with a
web-based forum. They use the issue tracker for RFCs, where PHP uses a
mix of wiki and nominated discussion threads, but you started this
thread talking about the discussions, not the RFCs.
Regards,
--
Rowan Collins
[IMSoP]
Are you being serious? Can you provide examples of projects that have
successfully replaced their developer mailing lists with GitHub issues?I already have. iojs (and soon, nodejs), as well as Rust which was
mentioned by someone else.I don't know about io/node, but Rust most certainly have not replaced a
mailing list with the issue tracker; they've replaced it with a
web-based forum. They use the issue tracker for RFCs, where PHP uses a
mix of wiki and nominated discussion threads, but you started this
thread talking about the discussions, not the RFCs.Regards,
Yeah, issue tracking isn't really the right thing for daily discussions.
A forum would be a reasonable alternative to a mailing list, however.
--
Stephen Coakley
A forum would be a reasonable alternative to a mailing list, however.
Yahoo groups is a forum style on-line but still retains a perfectly
functional email interface. WHY does the discussion have to be 'switch
to a forum' when there are perfectly good examples of multiple path
systems without the straigh jacket some forum systems enforce?
github does provide a reasonable email interface but only once you have
connected with a thread. However what github prevents is cross inking
with the rest of the php infrastucture, so bugs can be linked with
releases, the manual can directly link to RFC's and other source
material, and the whole system is independent of ANY third party policy
changes.
Yes things can be improved, and even some of the poor choices on the
existing infrastructure could be replaced, (mirroring wiki for example!)
but hopefully that will happen in isolation to third party services,
while still allowing mirroring via them as already happens with github,
email archives, and other third party services.
--
Lester Caine - G8HFL
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk
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)
I made a similar suggestion (of using a new medium of discussion, the
specifics differ) here:
https://www.reddit.com/r/PHP/comments/3bxh5h/centralizing_php_discussion_and_communication/
and was basically turned down flat.
Personally, I'd like to see the mailing list move to a forum-type
system. Lower barrier of entry, more visible archives, and more modern
medium that supports other kinds of attachments and whatnot.
The mailing list has been here for a long time, and it will be an uphill
battle if you want to have this discussion. I'm sure many people would
be open to the idea, but many also will not be. I'd love to be proved
wrong, though.
--
Stephen Coakley
Personally, I'd like to see the mailing list move to a forum-type
system. Lower barrier of entry, more visible archives, and more modern
medium that supports other kinds of attachments and whatnot.
I don't buy the "lower barrier of entry" argument.
Forum:
- Sign up via web form
- Get authentication email
- click on it, be logged in or not
- post
List:
- Sign up via web form
- Get authentication mail
- reply
- post
Someone iirc said you can even reply without signing up, so it might be
even lower. Unless you're saying people don't know what a mailing list
is or how it works - then ok. The same could be said for any type of
web-based infrastructure.
My actual main gripe with forums is that you can't skim it as easily (if
you're not reading every thread) because everything is split up into
subforums and paginated and whatnot. Or would "internals" be one subforum?
~Florian
Personally, I'd like to see the mailing list move to a forum-type
system. Lower barrier of entry, more visible archives, and more modern
medium that supports other kinds of attachments and whatnot.I don't buy the "lower barrier of entry" argument.
Forum:
- Sign up via web form
- Get authentication email
- click on it, be logged in or not
- post
List:
- Sign up via web form
- Get authentication mail
- reply
- post
Someone iirc said you can even reply without signing up, so it might be
even lower. Unless you're saying people don't know what a mailing list
is or how it works - then ok. The same could be said for any type of
web-based infrastructure.My actual main gripe with forums is that you can't skim it as easily (if
you're not reading every thread) because everything is split up into
subforums and paginated and whatnot. Or would "internals" be one subforum?~Florian
My thought is that no, a number of people don't know what a mailing list
is (obviously no one in here already), but everyone knows what a forum
is. The web is everywhere and is taking over the world, whereas mailing
lists are not. I'm not saying we should jump on the bandwagon, but that
a forum (or other web-based system) has a "lower barrier" because people
already understand that barrier. You are right though, it makes no
difference to someone who understands neither mailing lists nor forums.
My only real beef with the current system is this:
- Don't mind tons of email -> mailing list
- Do mind tons of email -> really old news server
Not a problem for those who don't mind tons of email, but if you do, you
need to get a client for a really old protocol.
--
Stephen Coakley
Am 04.08.2015 um 19:47 schrieb Stephen Coakley me@stephencoakley.com:
[...]
My thought is that no, a number of people don't know what a mailing list is (obviously no one in here already), but everyone knows what a forum is. The web is everywhere and is taking over the world, whereas mailing lists are not. I'm not saying we should jump on the bandwagon, but that a forum (or other web-based system) has a "lower barrier" because people already understand that barrier. You are right though, it makes no difference to someone who understands neither mailing lists nor forums.
My only real beef with the current system is this:
- Don't mind tons of email -> mailing list
- Do mind tons of email -> really old news server
Not a problem for those who don't mind tons of email, but if you do, you need to get a client for a really old protocol.
Can we please stop this nonsense abot protocol age? I mean HTTP is not much younger than NNTP (1986 to 1989) and the latest RFC for NNTP is from 2009 so not really that old.
In my eyes this whole discussion about "lowering the entry barrier" is in the end a discussion about "let's bring it all to HTTP". The internet is so much more than HTTP. And the internet is so much more than an implementation of that protocol by any service provider be it google or yahoo or whatnot.
Cheers
Andreas
--
Andreas Heigl
andreas@heigl.org