python-organizers / conferences

List of Python Conferences around the World
191 stars 89 forks source link

Update some links, remove year from conferences #223

Closed JesperDramsch closed 5 months ago

JesperDramsch commented 5 months ago

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

Link updates:

Country updates:

JesperDramsch commented 5 months ago

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

So you want me to add them back?

invisibleroads commented 5 months ago

@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 commented 5 months ago

@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 commented 5 months ago

@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 commented 5 months ago

@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 commented 5 months ago

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 commented 5 months ago

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 commented 5 months ago

@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.