I've created a new ML thread which has the attachments. On Sat, Oct 4, 2014 at 7:20 AM, Paul Dragoonis <[email protected]> wrote:
> > On 4 Oct 2014 03:20, "Eli" <[email protected]> wrote: > > > > This raises a few questions for me: > > > > 1. What does it actually 'put' on the /conferences/ page? Because > currently one of the most useful things about /conferences/ IMO is that > it's not just a raw listing of conferences. Joind.in itself is already > that, as is Lanyrd, as is a few other websites. If all > php.net/conferences/ is to to become is a copy of joind.in - Then why not > just replace /conferences/ with a link to joind.in? (which I'm not > arguing for) > > The really useful part of /conferences/ to me is that it's > announcements. CfP's are announced, conference schedules are announced. > And the verbiage used isn't "dead" description of a conference text. But > vibrant 'announcement' style text. (Does that make any sense? Does in my > mind at least). > > We will use joindin as one of many data suppliers of PHP conferences, this > will mature over time. > > > > > 2. How does the code 'detect' what conferences to actually list? > Joind.in (while heavily used by the PHP community, and started in the PHP > community) is a generic conference tool. And there are many non-PHP > conferences on it. Plus there's a question about the listing of non-broad > PHP conferences (such as WordCamps and DrupalCamps and etc that would > appear as well. > > While on the surface having all those listed would not be a horrible > thing - It very much changes the feel of the current /conferences/ page, > and the page would be flooded by many of those (especially as many meetups > are beginning to put their monthly meetings on joind.in). You'd almost > need some sort of smart filtering, or a human approval process each time. > > So I'm not sure (offhand, perhaps this has been solved), how to > solve this dilemna. > > Each conf has tags and I filter their API call with a 'php' tag to only > include PHP confs. > > > > > 3. How does this system handle conferences that don't use joind.in? > There are some (such as ConFoo) that traditionally have posted themselves > to /conferences/; however who choose not to list themselves on joind.in > for various reasons (and won't list themselves on there at this point). > > It would seem 'awkward' for php.net to demand that people use a > specific talk-rating system website, in order to list your conference on > php.net. So is there a way built into this to still allow conferences > who choose not to use joind.in to publish to /conferences/ ? > > We will need to discuss this separately after this integration is over. > > > > > 4. Has there been thought to maintenance of this towards joind.in v2 -- > I know that joind.in is being actively worked on, with plans to > eventually scrap the codebase and replace it with all new, including an > all-new API (from last I heard). I assume that this is built towards the > old API - So it would need updated if php.net relied upon it. It would > become an external dependency. > > It doesn't matter from a php.net point of view, we are abstracted behind > an API. That's an internal matter for them. The data is the same. > > > > > Not trying to rain in any parades Paul - It sounds like some cool > code. There just seems to be quite a few issues with the concept on the > surface. > > > > Eli > > > > > > > > > > On 10/3/14 7:07 PM, Paul Dragoonis wrote: > >> > >> Hi Team, > >> > >> At the PHPNW14 hackathon I've contributed my time to improve the > integration between joindin PHP events and the existing php.net setup. > >> > >> I have tested the code and it's working nicely, I would appreciate any > feedback but I'm happy with the code as is and will look to improve it in > time once an initial merge happens. > >> > >> This code patch is in 2 parts, > >> > >> 1) (attachment 1) Adding an update-backend hook which parses the > joind.in API and dumps the data to disk which is readable by mirrors. > >> > >> 2) (attachment 2) Updating the /conferences/ page to list the new data > that was dumped out by the first section. > >> > >> Many thanks, > >> Paul > >> > >> > >> > >> > >> > >> > > > > -- > > | Eli White | http://eliw.com/ | Twitter: EliW | >
