Event Name and Numbers about datasaturdays HOT 22 CLOSED

IMHO, we need to introduce sub domains, like losangeles.datasaturdays.com that will go the https://www.sqlsaturday.com/978 (current/latest event). this way the organizers have one permanent link to share.

from datasaturdays.

I like the non numeric hashtags too, especially since events repeat, so I would use the same hashtag for the same event year after year

from datasaturdays.

I like @amtwo s comment on both. A vanity for the current event and the number for historical purposes. This would mean that while the event is the most recent, both of these urls would point to the same content:

datasaturdays.com/pordeone
datasaturdays.com/0001

In 2021, if there is a new event, then these would point to the same content

datasaturdays.com/pordeone
datasaturdays.com/0101

while datasaturdays.com/0001 would still exist as a historical reference.

from datasaturdays.

An idea could be just to use MonthYear like:

• #DataSatLisbon0521
  (#DataSat122)
• #DataSatLisbon1121
  (#DataSat123)
• #DataSatParma1121
  (#DataSat124)
• #DataSatSlovenia1221
  (#DataSat125)

I think that this is self-explanatory. Yes, you lose the milestone, but you can always use a sequence for all the events. In most of cases, you can omit the month part and, optionally also the year part, depending on how we would like to get:

Option 1: #DataSatSlovenia
Option 2: #DataSatSlovenia21

If we would like to have a standard unique way, we could use #DataSatCityMMYY.
Just my two cents.

from datasaturdays.

This would solve another problem with the old urls; when searching for e.g. "SQL Saturday Lisbon" it was invariably the previous years' events that came up first in the search results as they had more inbound links.

from datasaturdays.

Re: domains, I do not want to manage subdomains, and I suspect no one else desires this task. I could envision

datasaturdays.com/xxxx
datasaturdays.com/yyyy
datasaturdays.com/zzzz

where [xxxx|yyyy|zzzz] could be a name of a city or number.

from datasaturdays.

from datasaturdays.

Opening up for multiple events per year is good, flexibility is great.
Another option could be to number only per city/site - but then you would miss the milestones.

from datasaturdays.

As hashtags are becoming unique less often, this is a good suggestion and to remember, whatever comes up first for numbering and alphabet wins in the auto-populate... :)

from datasaturdays.

This would solve another problem with the old urls; when searching for e.g. "SQL Saturday Lisbon" it was invariably the previous years' events that came up first in the search results as they had more inbound links.

I think the year should be part of the tag.

from datasaturdays.

IMHO, we need to introduce sub domains, like losangeles.datasaturdays.com that will go the https://www.sqlsaturday.com/978 (current/latest event). this way the organizers have one permanent link to share.

While in principle I like the idea of subdomains, they do introduce a level of management and cost overhead. Unless a wildcart certificate is obtained for the parent domain, or potentially multiple root domains there covering all the subdomains can become costly. I think a similar concept could be accomplished by having a branch off the main site, (ex: datasaturdays.com/losangeles) that would link to all of the events for the city. That would allow a single certificate per parent domain to cover and not require any administrative changes when a new city event is requested.

from datasaturdays.

To support the first few events, we are restarting numbering at 0001. These may be exceptions, so do not take these as any suggestion or requirement from the organizers that we continue with this schema.

The discussion above will need to resolve into some sort of naming/numbering.

from datasaturdays.

If we continue the route of github pages, some Jekyll templates offer the possibility of supporting an "event" breakdown by "front matter" which is defined by a YAML template that starts the beginning of each markdown post located in the _posts directory. If we utilize the predefined variables for posts which include categories, tags and date we could create a pretty effective structure that would allow us to build out an event page archive quickly and easily.

https://jekyllrb.com/docs/front-matter/

from datasaturdays.

Jekyll is something we've talked about. I don't know if static pages are sustainable long term, as more tooling is likely needed, but this isn't a bad idea.

from datasaturdays.

Why not both?!

• Sequence numbering provides certain benefits, as does name-based numbering.
• The concern with managing different sub domains is justified.
• Permalinks to past events are valuable, particularly for MVPs who need to track our community contributions and need to ensure the event page is accessible for up to 15 months post-event.

It would probably be easier to manage a scheme where UG organizers who are hosting a local event get a "vanity address" url like https://datasaturdays.com/bostonsql which is simply a 301 redirect to the numeric permalink. When a UG spins up a new event, part of the PR can be to update the 301 on the "vanity address" to the new permalink. The vanity address would always be the most recent event, allowing the UG to print the URL on physical items for use at in-person events.

from datasaturdays.

Accessibility Links:
Audio Link:https://gofile.io/d/qGJOQH
Image Link:https://gofile.io/d/tF52Cy

from datasaturdays.

Accessibility Links:
Audio Link:https://gofile.io/d/oRmAYp
Image Link:https://gofile.io/d/DvlOFJ

from datasaturdays.

Accessibility Links:
Audio Link:https://gofile.io/d/lJrInn
Image Link:https://gofile.io/d/PDudkC

from datasaturdays.

I bought sqlsatnash.com and forward it to the current event, had planned on a static page for in the off season. It was the best $15 ever spent as I don't have to update documents, email templates or tweets. I've also stuck with #sqlsatnash and really use the actual event number rarely, but it is on the pint glasses. Unless I am told I can't use these I will more than likely stick with our logo and these and just use forwarding to where ever we land.

from datasaturdays.

Accessibility Links:
Audio Link:https://gofile.io/d/pKnvoT
Image Link:https://gofile.io/d/TjDExq

from datasaturdays.

@tameraclark I suspect your ability to actively use "SQLSat" going forward is going to be impacted by how the SQLSaturday brand is sold, and who buys it. Your ability to use "SQLSat" is covered under the license agreement with PASS that you sign for each event. If someone were to purchase the SQLSaturday brand and wants to defend their trademark, you'd be at risk of being sued by the new trademark holder.

Unfortunately, we don't know exactly what SQLSat assets are being sold, and we won't know who the new owner is until the sale is complete. Continuing to forward the domain to a new home will be no big deal--but continuing to advertise with it & use it on materials could be an issue. I'm not a lawyer, and this isn't legal advice--but if you want to use that going forward on any materials you might want to ask a lawyer about it.

from datasaturdays.

Naming convention in dynamic instructions in wiki

from datasaturdays.