Re: [PHP-DEV] Move internals discussion to a better medium
Hi, Rowan 2015-08-03 4:31 GMT-03:00 Rowan Collins rowan.coll...@gmail.com: On 2 August 2015 23:35:38 GMT+01:00, Marcio Almada marcio.w...@gmail.com wrote: 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On Tue, 4 Aug 2015, Ferenc Kovacs wrote: On Tue, Aug 4, 2015 at 7:18 PM, Scott Arciszewski sc...@paragonie.com wrote: On Tue, Aug 4, 2015 at 12:36 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Aug 4, 2015 at 6:12 PM, Terry Cullen te...@terah.com.au wrote: On Tuesday, 4 August 2015, Johannes Schlüter johan...@schlueters.de wrote: On Sun, 2015-08-02 at 17:15 -0500, Stephen Coakley 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/Features 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. 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On Tue, 2015-08-04 at 18:36 +0200, Ferenc Kovacs wrote: 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 tht 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On Tue, Aug 4, 2015 at 7:18 PM, Scott Arciszewski sc...@paragonie.com wrote: On Tue, Aug 4, 2015 at 12:36 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Aug 4, 2015 at 6:12 PM, Terry Cullen te...@terah.com.au wrote: On Tuesday, 4 August 2015, Johannes Schlüter johan...@schlueters.de wrote: On Sun, 2015-08-02 at 17:15 -0500, Stephen Coakley 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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 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 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
Re: [PHP-DEV] Move internals discussion to a better medium
On 04.08.2015 at 19:30, Stephen Coakley wrote: On 08/04/2015 11:36 AM, Ferenc Kovacs wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On Tue, Aug 4, 2015 at 6:12 PM, Terry Cullen te...@terah.com.au wrote: On Tuesday, 4 August 2015, Johannes Schlüter johan...@schlueters.de wrote: On Sun, 2015-08-02 at 17:15 -0500, Stephen Coakley 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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 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
Re: [PHP-DEV] Move internals discussion to a better medium
On 08/04/2015 11:36 AM, Ferenc Kovacs wrote: On Tue, Aug 4, 2015 at 6:12 PM, Terry Cullen te...@terah.com.au wrote: On Tuesday, 4 August 2015, Johannes Schlüter johan...@schlueters.de wrote: On Sun, 2015-08-02 at 17:15 -0500, Stephen Coakley 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On Tuesday, 4 August 2015, Johannes Schlüter johan...@schlueters.de wrote: On Sun, 2015-08-02 at 17:15 -0500, Stephen Coakley 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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 --
Re: [PHP-DEV] Move internals discussion to a better medium
On Tue, Aug 4, 2015 at 12:36 PM, Ferenc Kovacs tyr...@gmail.com wrote: On Tue, Aug 4, 2015 at 6:12 PM, Terry Cullen te...@terah.com.au wrote: On Tuesday, 4 August 2015, Johannes Schlüter johan...@schlueters.de wrote: On Sun, 2015-08-02 at 17:15 -0500, Stephen Coakley 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php 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 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On 04/08/15 17:12, Terry Cullen wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On Aug 4, 2015, at 12:12 PM, Lester Caine les...@lsces.co.uk wrote: On 04/08/15 17:12, Terry Cullen wrote: 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? 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 - 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php Tom -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On 2 August 2015 23:35:38 GMT+01:00, Marcio Almada marcio.w...@gmail.com wrote: 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On 02/08/15 22:56, Stephen Coakley wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
Am 03.08.2015 um 09:31 schrieb Rowan Collins rowan.coll...@gmail.com: On 2 August 2015 23:35:38 GMT+01:00, Marcio Almada marcio.w...@gmail.com wrote: 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. 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On 08/03/2015 02:31 AM, Rowan Collins wrote: On 2 August 2015 23:35:38 GMT+01:00, Marcio Almada marcio.w...@gmail.com wrote: 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, 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On 02/08/15 13:52, Rowan Collins wrote: 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. 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
[PHP-DEV] Move internals discussion to a better medium
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)
Re: [PHP-DEV] Move internals discussion to a better medium
Hi Dor. Am 02.08.2015 um 14:01 schrieb Dor Tchizik d...@tchizik.com: Hello internals! I wanted to propose a change to how PHP discussions are made. Currently, PHP discussions are held on the various mailing lists, managed by an old mailing list system, without any proper alternative interface to follow and respond outside of mailing. The discussion is hidden away, deep within the mails and the archives, searching is nigh impossible for someone from the outside. Moreover, subscribing to internals and starting discussion has a *very high entry bar*, which is bad for any open source project (PHP is still considered an open source project, yes?). For example, ask a friend to try and find how to join in on the conversation, without mentioning the mailing list or the word internals. I propose that internals discussion to be moved (eventually entirely) to a different medium, where the example I have in mind is GitHub issues (but that is up for discussion). - Every developer worth his salt has a GitHub account. Finding the php project and looking at the issues is trivial. - GitHub issues can reference to people by name (triggering an explicit notification). - GitHub issues can reference other issues (currently impossible with the mailing list, unless you link to some archive, and then you can't really participate in the discussion, nor you have a guaranteed context for the rest of the discussion) - GitHub issues can be read and interacted with, from email. (Responding to an issue/commit comment notification will actually respond to the thread) - GitHub issues can reference commits directly. - GitHub commits can reference issues directly. - You can close GitHub issues. - GitHub issues are searchable. You have tags. - GitHub issues can be associated with milestones for easy reference. - You can comment on specific lines of a commit, and can reference files and line numbers from issue comments directly. - You don't need to maintain GitHub, like you do with the current system - Markdown formatting! There are probably more advantages I forgot to mention, but any developer who's familiar with GitHub (or BitBucket, or practically any other form of Git integration) knows of these free features and advantages, and most of them use them and take them for granted. Now, that's not to say the current system has no advantages over the current one. A few disadvantages of GitHub: - GitHub may be down (although I can probably count on one hand how many times that happened in the past several years) - GitHub's mailing system is not as robust as the mailing-list software. People who are exclusively used to emails will have to get used to a slightly different interface. - Moving to GitHub (or any other medium) would take some thinking and work done on the side of the people of internals. Personally, I think the advantages would seriously overweigh the disadvantages. PHP would enjoy a more robust discussion system, and a more open form of discussion, involving more people and more opinions. (I also have a matching workflow adjustment for the RFC process, but that can be discussed later) Is this the - in recent times becoming more and more popular - try to replace an open soure interface ( news://, smtp://, irc://, jabber://) with a closed source implementation (github, slack, hiphop, bitbucket)? 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 andr...@heigl.org -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On Sun, Aug 2, 2015 at 5:29 PM Andreas Heigl andr...@heigl.org wrote: Hi Dor. Am 02.08.2015 um 14:01 schrieb Dor Tchizik d...@tchizik.com: Hello internals! I wanted to propose a change to how PHP discussions are made. Currently, PHP discussions are held on the various mailing lists, managed by an old mailing list system, without any proper alternative interface to follow and respond outside of mailing. The discussion is hidden away, deep within the mails and the archives, searching is nigh impossible for someone from the outside. Moreover, subscribing to internals and starting discussion has a *very high entry bar*, which is bad for any open source project (PHP is still considered an open source project, yes?). For example, ask a friend to try and find how to join in on the conversation, without mentioning the mailing list or the word internals. I propose that internals discussion to be moved (eventually entirely) to a different medium, where the example I have in mind is GitHub issues (but that is up for discussion). - Every developer worth his salt has a GitHub account. Finding the php project and looking at the issues is trivial. - GitHub issues can reference to people by name (triggering an explicit notification). - GitHub issues can reference other issues (currently impossible with the mailing list, unless you link to some archive, and then you can't really participate in the discussion, nor you have a guaranteed context for the rest of the discussion) - GitHub issues can be read and interacted with, from email. (Responding to an issue/commit comment notification will actually respond to the thread) - GitHub issues can reference commits directly. - GitHub commits can reference issues directly. - You can close GitHub issues. - GitHub issues are searchable. You have tags. - GitHub issues can be associated with milestones for easy reference. - You can comment on specific lines of a commit, and can reference files and line numbers from issue comments directly. - You don't need to maintain GitHub, like you do with the current system - Markdown formatting! There are probably more advantages I forgot to mention, but any developer who's familiar with GitHub (or BitBucket, or practically any other form of Git integration) knows of these free features and advantages, and most of them use them and take them for granted. Now, that's not to say the current system has no advantages over the current one. A few disadvantages of GitHub: - GitHub may be down (although I can probably count on one hand how many times that happened in the past several years) - GitHub's mailing system is not as robust as the mailing-list software. People who are exclusively used to emails will have to get used to a slightly different interface. - Moving to GitHub (or any other medium) would take some thinking and work done on the side of the people of internals. Personally, I think the advantages would seriously overweigh the disadvantages. PHP would enjoy a more robust discussion system, and a more open form of discussion, involving more people and more opinions. (I also have a matching workflow adjustment for the RFC process, but that can be discussed later) Is this the - in recent times becoming more and more popular - try to replace an open soure interface ( news://, smtp://, irc://, jabber://) with a closed source implementation (github, slack, hiphop, bitbucket)? Nah, an open source Git integration with an issue tracker, or even a simple forum would be tons better than the mailing list. GitHub is just an example, but I think it has many useful features. The mailinglist might be far from perfect (which some people also say about PHP so there's a good match) but it is a well established way of communication in the PHP-community. I strongly believe that it would be counterproductive to change the way of communication of the core contributors for the sake of probanly getting two or three more contributors. At least as long as the alternative is at least as faulty as the current way of communication. What makes you think that two or three more contributors is what you'd get? The nodejs org on GitHub is almost 400 strong. And to be honnest: For me it shows a certain understanding of the way the web works when you are able to setup your tools to be able to follow the discussions on internals. And I'm not sure Whether I want someone messing arround with the language that powers 80% of the WorldWideWeb who isn't able to get his tools set up properly. But that's just my 2 arrogant cent. Oh, I'm able to set my tools. The question is, am I willing to put this much time and effort, when *you're* (you as in the PHP core team) should be asking and encouraging *me* for contribution, and end up saying things like if you can't
Re: [PHP-DEV] Move internals discussion to a better medium
Hi, 2015-08-02 9:01 GMT-03:00 Dor Tchizik d...@tchizik.com: Hello internals! I wanted to propose a change to how PHP discussions are made. Currently, PHP discussions are held on the various mailing lists, managed by an old mailing list system, without any proper alternative interface to follow and respond outside of mailing. The discussion is hidden away, deep within the mails and the archives, searching is nigh impossible for someone from the outside. Moreover, subscribing to internals and starting discussion has a *very high entry bar*, which is bad for any open source project (PHP is still considered an open source project, yes?). For example, ask a friend to try and find how to join in on the conversation, without mentioning the mailing list or the word internals. I propose that internals discussion to be moved (eventually entirely) to a different medium, where the example I have in mind is GitHub issues (but that is up for discussion). - Every developer worth his salt has a GitHub account. Finding the php project and looking at the issues is trivial. - GitHub issues can reference to people by name (triggering an explicit notification). - GitHub issues can reference other issues (currently impossible with the mailing list, unless you link to some archive, and then you can't really participate in the discussion, nor you have a guaranteed context for the rest of the discussion) - GitHub issues can be read and interacted with, from email. (Responding to an issue/commit comment notification will actually respond to the thread) - GitHub issues can reference commits directly. - GitHub commits can reference issues directly. - You can close GitHub issues. - GitHub issues are searchable. You have tags. - GitHub issues can be associated with milestones for easy reference. - You can comment on specific lines of a commit, and can reference files and line numbers from issue comments directly. - You don't need to maintain GitHub, like you do with the current system - Markdown formatting! There are probably more advantages I forgot to mention, but any developer who's familiar with GitHub (or BitBucket, or practically any other form of Git integration) knows of these free features and advantages, and most of them use them and take them for granted. Now, that's not to say the current system has no advantages over the current one. A few disadvantages of GitHub: - GitHub may be down (although I can probably count on one hand how many times that happened in the past several years) - GitHub's mailing system is not as robust as the mailing-list software. People who are exclusively used to emails will have to get used to a slightly different interface. - Moving to GitHub (or any other medium) would take some thinking and work done on the side of the people of internals. Personally, I think the advantages would seriously overweigh the disadvantages. PHP would enjoy a more robust discussion system, and a more open form of discussion, involving more people and more opinions. (I also have a matching workflow adjustment for the RFC process, but that can be discussed later) As you pointed github issues, it's worth noting that Rust internals already use github to manage RFCs: https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AT-lang For general discussion and pre RFCs they are using their own discuss instance. You can login with github in 2 clicks or simply lurk and search through the threads: https://internals.rust-lang.org/ My 2 cents is that this was an exemplary way to get the community onboard their project. Marcio. -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On 2 August 2015 13:01:57 BST, Dor Tchizik d...@tchizik.com wrote: 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 QA 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On 02/08/15 15:29, Andreas Heigl wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On 02/08/2015 20:00, Dor Tchizik wrote: 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On 02 Aug 2015, at 22:03, Niklas Keller m...@kelunik.com wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
This is what I think. The best way to deter the community from making contributions is to make it hard to contribute. My C/C++ savvy buddy told me about an awesome feature he wants to see in iojs, I can tell him to go on GitHub and raise the issue, discussion took place, and he'd submitted a pull request, which subsequently got accepted. The entire process took two days, mainly due to timezone differences. Everyone were helpful and to the point. Now, I get that the RFC process in PHP is different, but why is it that to even GET on the mailing list one needs to go through seven hells, only to be in the discussion (often completely irrelevant to what he's trying to do) for several weeks or months, to get Karma, and only then may he submit an RFC? Why can't someone just open an issue, and have an RFC up and ready the next day (or even the next week)? It's this exact approach that pushes valuable community members away, several members of internals whom I value had left internals for various reasons, mostly regarding the atmosphere in the mailing list. And the way you improve the atmosphere is to get more people, more eyes, more opinions. On Sun, Aug 2, 2015 at 10:10 PM Marcio Almada marcio.w...@gmail.com wrote: Hi, 2015-08-02 9:01 GMT-03:00 Dor Tchizik d...@tchizik.com: Hello internals! I wanted to propose a change to how PHP discussions are made. Currently, PHP discussions are held on the various mailing lists, managed by an old mailing list system, without any proper alternative interface to follow and respond outside of mailing. The discussion is hidden away, deep within the mails and the archives, searching is nigh impossible for someone from the outside. Moreover, subscribing to internals and starting discussion has a *very high entry bar*, which is bad for any open source project (PHP is still considered an open source project, yes?). For example, ask a friend to try and find how to join in on the conversation, without mentioning the mailing list or the word internals. I propose that internals discussion to be moved (eventually entirely) to a different medium, where the example I have in mind is GitHub issues (but that is up for discussion). - Every developer worth his salt has a GitHub account. Finding the php project and looking at the issues is trivial. - GitHub issues can reference to people by name (triggering an explicit notification). - GitHub issues can reference other issues (currently impossible with the mailing list, unless you link to some archive, and then you can't really participate in the discussion, nor you have a guaranteed context for the rest of the discussion) - GitHub issues can be read and interacted with, from email. (Responding to an issue/commit comment notification will actually respond to the thread) - GitHub issues can reference commits directly. - GitHub commits can reference issues directly. - You can close GitHub issues. - GitHub issues are searchable. You have tags. - GitHub issues can be associated with milestones for easy reference. - You can comment on specific lines of a commit, and can reference files and line numbers from issue comments directly. - You don't need to maintain GitHub, like you do with the current system - Markdown formatting! There are probably more advantages I forgot to mention, but any developer who's familiar with GitHub (or BitBucket, or practically any other form of Git integration) knows of these free features and advantages, and most of them use them and take them for granted. Now, that's not to say the current system has no advantages over the current one. A few disadvantages of GitHub: - GitHub may be down (although I can probably count on one hand how many times that happened in the past several years) - GitHub's mailing system is not as robust as the mailing-list software. People who are exclusively used to emails will have to get used to a slightly different interface. - Moving to GitHub (or any other medium) would take some thinking and work done on the side of the people of internals. Personally, I think the advantages would seriously overweigh the disadvantages. PHP would enjoy a more robust discussion system, and a more open form of discussion, involving more people and more opinions. (I also have a matching workflow adjustment for the RFC process, but that can be discussed later) As you pointed github issues, it's worth noting that Rust internals already use github to manage RFCs: https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3AT-lang For general discussion and pre RFCs they are using their own discuss instance. You can login with github in 2 clicks or simply lurk and search through the threads: https://internals.rust-lang.org/ My 2 cents is that this was an exemplary way to get
Re: [PHP-DEV] Move internals discussion to a better medium
On Sun, Aug 2, 2015 at 10:05 PM Dor Tchizik d...@tchizik.com wrote: I already have. iojs (and soon, nodejs), as well as Rust which was mentioned by someone else. On Sun, Aug 2, 2015 at 11:04 PM Stig Bakken s...@stigbakken.com wrote: 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
Re: [PHP-DEV] Move internals discussion to a better medium
On 02/08/2015 21:19, Marcio Almada wrote: Hi 2015-08-02 16:52 GMT-03:00 Rowan Collins rowan.coll...@gmail.com: On 02/08/2015 20:10, Marcio Almada wrote: 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 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/-rust-governance.md Regards, -- Rowan Collins [IMSoP] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On 08/02/2015 07:52 AM, Rowan Collins wrote: On 2 August 2015 13:01:57 BST, Dor Tchizik d...@tchizik.com wrote: 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 QA 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On 08/02/2015 05:35 PM, Marcio Almada wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On 02/08/2015 20:10, Marcio Almada wrote: 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). On 02/08/2015 20:17, Dor Tchizik wrote: 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On Sun, Aug 2, 2015 at 11:04 PM Stig Bakken s...@stigbakken.com wrote: Are you being serious? Can you provide examples of projects that have successfully replaced their developer mailing lists with GitHub issues? On 02/08/2015 21:05, Dor Tchizik wrote: 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] -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On 08/02/2015 03:34 PM, Rowan Collins wrote: On Sun, Aug 2, 2015 at 11:04 PM Stig Bakken s...@stigbakken.com wrote: Are you being serious? Can you provide examples of projects that have successfully replaced their developer mailing lists with GitHub issues? On 02/08/2015 21:05, Dor Tchizik wrote: 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 -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
On Sun, 2015-08-02 at 19:17 +, Dor Tchizik wrote: 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 signature.asc Description: This is a digitally signed message part
Re: [PHP-DEV] Move internals discussion to a better medium
On Sun, Aug 2, 2015 at 2:02 PM Dor Tchizik d...@tchizik.com wrote: Hello internals! I wanted to propose a change to how PHP discussions are made. Currently, PHP discussions are held on the various mailing lists, managed by an old mailing list system, without any proper alternative interface to follow and respond outside of mailing. The discussion is hidden away, deep within the mails and the archives, searching is nigh impossible for someone from the outside. Moreover, subscribing to internals and starting discussion has a *very high entry bar*, which is bad for any open source project (PHP is still considered an open source project, yes?). For example, ask a friend to try and find how to join in on the conversation, without mentioning the mailing list or the word internals. I propose that internals discussion to be moved (eventually entirely) to a different medium, where the example I have in mind is GitHub issues (but that is up for discussion). - Every developer worth his salt has a GitHub account. Finding the php project and looking at the issues is trivial. - GitHub issues can reference to people by name (triggering an explicit notification). - GitHub issues can reference other issues (currently impossible with the mailing list, unless you link to some archive, and then you can't really participate in the discussion, nor you have a guaranteed context for the rest of the discussion) - GitHub issues can be read and interacted with, from email. (Responding to an issue/commit comment notification will actually respond to the thread) - GitHub issues can reference commits directly. - GitHub commits can reference issues directly. - You can close GitHub issues. - GitHub issues are searchable. You have tags. - GitHub issues can be associated with milestones for easy reference. - You can comment on specific lines of a commit, and can reference files and line numbers from issue comments directly. - You don't need to maintain GitHub, like you do with the current system - Markdown formatting! There are probably more advantages I forgot to mention, but any developer who's familiar with GitHub (or BitBucket, or practically any other form of Git integration) knows of these free features and advantages, and most of them use them and take them for granted. Now, that's not to say the current system has no advantages over the current one. A few disadvantages of GitHub: - GitHub may be down (although I can probably count on one hand how many times that happened in the past several years) - GitHub's mailing system is not as robust as the mailing-list software. People who are exclusively used to emails will have to get used to a slightly different interface. - Moving to GitHub (or any other medium) would take some thinking and work done on the side of the people of internals. Personally, I think the advantages would seriously overweigh the disadvantages. PHP would enjoy a more robust discussion system, and a more open form of discussion, involving more people and more opinions. (I also have a matching workflow adjustment for the RFC process, but that can be discussed later) Are you being serious? Can you provide examples of projects that have successfully replaced their developer mailing lists with GitHub issues? - Stig
Re: [PHP-DEV] Move internals discussion to a better medium
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
Re: [PHP-DEV] Move internals discussion to a better medium
I already have. iojs (and soon, nodejs), as well as Rust which was mentioned by someone else. On Sun, Aug 2, 2015 at 11:04 PM Stig Bakken s...@stigbakken.com wrote: On Sun, Aug 2, 2015 at 2:02 PM Dor Tchizik d...@tchizik.com wrote: Hello internals! I wanted to propose a change to how PHP discussions are made. Currently, PHP discussions are held on the various mailing lists, managed by an old mailing list system, without any proper alternative interface to follow and respond outside of mailing. The discussion is hidden away, deep within the mails and the archives, searching is nigh impossible for someone from the outside. Moreover, subscribing to internals and starting discussion has a *very high entry bar*, which is bad for any open source project (PHP is still considered an open source project, yes?). For example, ask a friend to try and find how to join in on the conversation, without mentioning the mailing list or the word internals. I propose that internals discussion to be moved (eventually entirely) to a different medium, where the example I have in mind is GitHub issues (but that is up for discussion). - Every developer worth his salt has a GitHub account. Finding the php project and looking at the issues is trivial. - GitHub issues can reference to people by name (triggering an explicit notification). - GitHub issues can reference other issues (currently impossible with the mailing list, unless you link to some archive, and then you can't really participate in the discussion, nor you have a guaranteed context for the rest of the discussion) - GitHub issues can be read and interacted with, from email. (Responding to an issue/commit comment notification will actually respond to the thread) - GitHub issues can reference commits directly. - GitHub commits can reference issues directly. - You can close GitHub issues. - GitHub issues are searchable. You have tags. - GitHub issues can be associated with milestones for easy reference. - You can comment on specific lines of a commit, and can reference files and line numbers from issue comments directly. - You don't need to maintain GitHub, like you do with the current system - Markdown formatting! There are probably more advantages I forgot to mention, but any developer who's familiar with GitHub (or BitBucket, or practically any other form of Git integration) knows of these free features and advantages, and most of them use them and take them for granted. Now, that's not to say the current system has no advantages over the current one. A few disadvantages of GitHub: - GitHub may be down (although I can probably count on one hand how many times that happened in the past several years) - GitHub's mailing system is not as robust as the mailing-list software. People who are exclusively used to emails will have to get used to a slightly different interface. - Moving to GitHub (or any other medium) would take some thinking and work done on the side of the people of internals. Personally, I think the advantages would seriously overweigh the disadvantages. PHP would enjoy a more robust discussion system, and a more open form of discussion, involving more people and more opinions. (I also have a matching workflow adjustment for the RFC process, but that can be discussed later) Are you being serious? Can you provide examples of projects that have successfully replaced their developer mailing lists with GitHub issues? - Stig
Re: [PHP-DEV] Move internals discussion to a better medium
Hi 2015-08-02 16:52 GMT-03:00 Rowan Collins rowan.coll...@gmail.com: On 02/08/2015 20:10, Marcio Almada wrote: 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 phase https://github.com/rust-lang/rfcs/pulls?q=is%3Aopen+is%3Apr+label%3Afinal-comment-period, as an example. Marcio -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP-DEV] Move internals discussion to a better medium
Hi, 2015-08-02 17:46 GMT-03:00 Rowan Collins rowan.coll...@gmail.com: On 02/08/2015 21:19, Marcio Almada wrote: Hi 2015-08-02 16:52 GMT-03:00 Rowan Collins rowan.coll...@gmail.com: On 02/08/2015 20:10, Marcio Almada wrote: 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 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. 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/-rust-governance.md I missed this one. This is really cool, thanks for pointing it out. Regards, -- Rowan Collins Thanks, Marcio -- PHP Internals - PHP Runtime Development Mailing List To unsubscribe, visit: http://www.php.net/unsub.php
