Structure for author, event and year

[Cactooz]

Currently, we don't have a unified system for how the structure of the author of a song is, where it was first sung and which year.

For example, Moder Kista has the author tag David Larsson, IT00 where David Larsson is the name of the author and IT00 is which year and the program he studied.

While on the other hand, Vikingen has the author tag Sångarstriden, Lund, 1981 where Sångarstriden is the event, Lund is the city of the event and 1981 is the year of the event/the year the song was made.

As you can clearly see, we have no real structure for the author tag. Therefore, I suggest two possible solutions:

1. Either we add more format information to the README and trust that everyone follows the correct author format.
2. We add new tags such as event and year (just suggestions, doesn't have to be exactly these tag names) where the event and optional city are added in the event tag and the year of the song creation is added in the year tag. The year tag could also be confusing, some people may think that it's the year the song was added to the songbook, so this idea might need more refinement.

If we go with the tags, then the code can automatically format the author's name, program, event and year into a predefined format. Where I suggest we use the following: FirstName "NickName" LastName, ProgramYear (Event, City, Year)

For example from Jag ska festa: Stefan "Stege" Gennert, D86, och Anders "Pellefjant" Bjerkén, D87 (Sångarstriden, Lund, 1987)

[StelFoog]

I think events being the "authors" songs is more of an exception so it would be a bit much to include a separate metadata field for that, just using the author field. I do however think that it's very resonable to have year created as separate field. This would allow any application to format years freely.

When it comes to program year and nickname I think that should be up to the author/contributor, so if someone is more identified by their nickname they can use only nickname as author and if someone wants to be identified with their program year it can be up to them. So that I think is better to leave on a "per PR" basis.

[StelFoog]

Thoughts @epicmeme?

[Cactooz]

Fair point with the nicknames and program-year. I didn't mean to force people to add them, but if you use them, it would be nice if all of them were formatted the same way. So an addition to the README is probably the only thing needed to keep it somewhat consistent.

Also sure that events are a bit more of an exception, but IMHO it's nice to see where a song is from if that is known. We also have quite a few songs where the actual event is actually written, but currently in the author tag. If that has its own part along with the year, then we could also format it easier for a more consistent look.

[StelFoog]

I think an addition to the README would be good.

Personally I'd like to have more of an understanding of how much this occurs before I'd like to add another field. Currently all fields are things that are applicable to nearly every song (even if the data is currently missing). The only songs where we can't realistically add data for fields is when the melody is a folk song, but many songs are written entirely without an event in mind. We'd also need to have a field for the event year then to keep consistency.

It's possible that it's a good addition, but atm it seems like it would be used very sporadically.

[Cactooz]

Yeah, I agree that it's probably not enough for the work to implement it when it's not going to be used that much. I'll look into our current songs how many have events and such.

But as you said earlier, year could possibly be a tag, however we might need to see how many songs even have a year. (Though it might be handy even if it's only a few, since you can then sort on years at least. If we want that feature.)

Anyhow, I'll just start writing a part in the README for how to format the author with some examples soon :)

[loffa]

I think we could make all the tags optional, and then create the auto-formatter with different output depending on the fields available.
It is usually good practice to only have one data point in each field.
The output formatter that makes the combined field could work based on if the field is set or not. Eg. If first name exist, put that first, if nickname is set, make that the second word, if none of the Event, City, Year exist skip the last parenthesis.

[Cactooz]

That is a really good way to do it! Then we don't have to check for formatting at every PR in the future.

I'll look into if I can manage to code that in and see how it works out in the end.