Merge with data of codeandtalk.com

[szabgab]

Merge with this repo: https://github.com/szabgab/codeandtalk.com which is used by this site: https://codeandtalk.com/

As a first step we can convert the data files of https://github.com/szabgab/codeandtalk.com/tree/main/data/events into json files that have a similar structure described in the README of this repo.

I think it would be better if we kept each even in its own file and we would generate the combined json ( which is now data/conferences.json in this repo) programmatically.

There is also a data/tags.json here which seems to serve similar purposes to the https://github.com/szabgab/codeandtalk.com/blob/main/data/tags.csv

Suggestions?

#91 https://github.com/szabgab/codeandtalk.com/issues/248

[ShaneCurcuru]

Keeping events (or event sets, if you're tracking one event over multiple years) in their own files is key. The giant single file JSON won't work long term. Storing in JSON is the defacto way to share data these days, so I definitely like that update. It makes it easy both for anyone to process, and especially easy for conference organizers to self-submit or update their data. Thanks for considering!

[afilina]

+1 on all accounts.

I recommend the following order:

• Split the JSON of this project into multiple files + update README (@szabgab?)
• Adapt the code of confoo.community to match the new structure (@afilina?)
• Import event data from codeandtalk into this project (@ShaneCurcuru?)
• Adapt the code of codeandtalk to match the new structure (@szabgab?)

[ShaneCurcuru]

The first thing is for the two of you to decide where to put the master list of conference data that we point organizers at for self-submissions. Is it worth considering a new repo, or use @szabgab repo, since he seems to have more data and meta-structure around it already?

Second is to figure if we want any standard for the top-level hash of individual conference data. For example, I think it's important to still ensure that the filename.json and/or the "key" value are assured unique for future data retrieval. You two have existing websites pulling/sorting/querying this data; I bet if we work together we'd get a bunch more people using the data directly too.

And yes, then those are good steps. 8-)

[szabgab]

IMHO it would be better to end up with a single repo owned by both @afilina and myself. Maybe we can have a GitHub organization for that. Optionally the code that serves the codeandtalk.com site could be moved to a separate repo.

I am not sure if we should have a separate file for each event as we have in the codeandtalk repo now, or if we should have a separate file for each event "series" as the entries are in the data/conferences.json . My current feeling is that the latter is better. So one file for each event series. Then inside that series we might have some global data that might be overridden by local data. (e.g. a generic twitter account and individual twitter accounts where relevant)

[rollandf]

+1 on having a new repo with both the data merged. I think the best will be one file for each event series with global data, with possibility to override in specific events.

[afilina]

I'll create a separate file for each event series, then modify my website to use those, then deprecate the master file.

[szabgab]

I think it would be better to convert:

"location" : { "name": "" }

to

"location" : { "city": "", "state": "", "country": "" }

I already have that (moved the 3 entries inside the location key) and clearly marking the fields will make the usage easier.

[szabgab]

In addition, I'd like to suggest we remove the '#' from the hashtag field and the '@' from the twitter field. During display it will be easier to add those than to remove them where we might need the value without the prefix. What do you think?

[ShaneCurcuru]

I agree with both of @szabgab suggestions. While city/state/country isn't strictly canonical for everywhere in the world, it's a good compromise for keeping it simple, and good enough for places with different addresses.

Question: do we want to consider adding a "venue" entry within location? I.e. the name of the hotel, conference center, or wherever the conference is being held. Again, it's not a complete description, but it's good enough in almost all cases to get viewers to the right place.

Thanks! I'm speaking at ApacheCon Miami all this week, but will have more free time to help at end of May.

[afilina]

Done:

• Split the JSON of this project into multiple files + update README
• Adapt the code of confoo.community to match the new structure