Update some links, remove year from conferences

[JesperDramsch]

Found a wrong link, so I merged what I had.

Link updates:

• Flask Con
• PyDay Valparaiso

Country updates:

• PyDay Copiapó
• PyDay Valparaiso
• Italy 2025

[jonafato]

I think I added most of the event years changed in this PR. For all but PyBay, the conference websites refer to the event with the year included. If the organizers of those events prefer to remove the year from the conference name, we should accept those changes, but we should defer to the websites as the source of truth otherwise.

[JesperDramsch]

Oh okay, it was just never included before, just with the last commit.

So you want me to add them back?

[invisibleroads]

@jonafato Thanks for adding those events earlier.

I think the rationale for removing the years is to make it easier to track a conference by name through multiple years. The only case this doesn't work is if a conference merges with another conference for a specific year. In the past, I also sometimes changed the conference display name to make it clearer which country or region was represented by the conference, especially when the two letter abbreviation was ambiguous.

I think as long as the link resolves to the correct webpage, we can make adjustments to the conference display name in order to maximize clarity/readability to a person who has never heard of a specific conference before.

In this case, I am in favor of @JesperDramsch's edits.

[invisibleroads]

@jonafato Do you feel strongly about respecting the conference organizer's original conference name including the year?

For example, I think PyCon Colombia was originally called PyCon CO in 2017. Reading it, I couldn't tell whether that meant Colorado or Colombia, so I renamed the CSV to read PyCon Colombia and I think the conference organizers adopted that name in later years. There were a few other cases like that too.

Personally, I didn't like the PyCon naming convention that trended towards acronyms/abbreviations and preferred the full country or region name, which I think is better for marketing if the goal is to attract newcomers to a conference.

[jonafato]

@invisibleroads I think this repository should aim to be consistent with event websites (i.e. descriptive rather than prescriptive). Editorializing event names is a subjective change that should involve the organizers, especially in the case of changing the way a region is stylized.

To your point about PyCon Colombia vs. PyColorado: this repository includes geographic information, official websites, and other details that more uniquely identify events in cases of confusion. If an event changes its name, updating past events retroactively can make sense.

[invisibleroads]

@jonafato
Ok, I agree with consulting the conference organizers before adjusting the conference display name. That is a valid point that respects the organizers.

But should we include the event year in the display name?

I think we can safely omit the event year from the display name, especially if the event will be appearing in a calendar.

Otherwise, all the conferences in 2024.csv would have 2024 appended to their display names.

Usually, when people do a google search, I think they search for PyGotham and not PyGotham 2024.

[jonafato]

Otherwise, all the conferences in 2024.csv would have 2024 appended to their display names.

I don't think this is universally true, but it's probably common. A distinction I'd like to make is that an instance of an event is different from a series of events, and their names are used differently (an event's details and location may vary from year to year). This repository wasn't really designed to capture that nuance, so I can see a case for either format.

In either case, I think that fixing incorrect website links and changing conference names are two unrelated changes that would be nice to have decoupled.

[JesperDramsch]

I just try to feed these back as a courtesy as a user of the dataset.

I have purposely not included fixes for wrong data that are non-obvious and would need more investigation, rather than these small changes.

This is a side project for me, and I'm just trying to be useful. But I have to be honest, if all my changes have to be submitted individually, I will probably prefer not to add these, as there's still a significant amount of manual labour involved with this. Just let me know which you prefer, as I don't mean to cause more work for you.

[invisibleroads]

@JesperDramsch We very much appreciate your edits and I think it is more important to encourage more contributions than to add more work to a pull request.

@jonafato Thanks for taking the time to think about these technical issues. I think we should omit the year/time from the event name and in general err on the side of accepting most pull requests in order to encourage more contributions unless they are obviously wrong.

Overall, I think @JesperDramsch's edits are good and his intentions are good.