Logs of specification changes

[TheSaunders]

There was some discussion on IRC about how this could be done, some of them were:

• Log all #IRCv3 chatter
• Log all #IRCv3 chatter + grep 'terms' and tag all lines within 50 lines of these 'terms' as relating to a certain issue. (The issue they would be tagged as would be the grepped term)
• Opening GitHub issues and/or gists

So, all three of these have their ups and downs:

Log-all Pro: This would be nice because any user could at any time read the backlog of the channel. Con: Not many people like the idea of public logging, and in the case of private information accidentally being put out, there's not a whole lot you can do.

Log-all + grep Pro: This is good for the same reason as the first, with the added benifit of being able to select the 'terms'/issues you wished to read backlog for, the grepping wouldn't be 100% perfect but it would work well enough for this, I believe. Con: This is also bad for the same reason as the first, not many people like public logging, etc. Also this has the added downfall of someone needing to write a script to grep + tag issues to lines or do it manually.

I thought this was a great idea when I suggested it but after taking some time to review how it would be implemented I don't think it would be worthwhile to take time to add this.

Open Github issues Pro: This is without a doubt the easiest one to implement. Before bringing up a discussion on IRC open a GitHub issue with all the relevent information about what you are suggesting and then ask for comments on IRC about how to go about it. This would require that the GitHub issue be updated whenever new information came up. Con: We may end up with lots of unused github issues and some github issues may not get updated with new information as they should.

---

All-in-all after looking over the three major options that were given on IRC, I'm in favor of the third option. This would require some slight changes to the way issues are updated but I think it would help sort out a couple of issues I see on IRC, those issues being:

• Constantly reitterating what was said previously because someone was absent
• Lack of any prior log of why a specification was changed

Now the account-tag issue for example, that went through at least 5 major changes since it was originally opened on github and due to there being no public log to why those changes happened some of them were reverted once and some multiple times, by the third or fourth itteration we were right back where the spec originally started before it changed again.

I think that all changes to a specification should not be squashed and the original commit messages should stand until it is ready to be merged into master so that during the on-going discussion there is a clear trail of what has happened and why.

Also, the issue-head should be updated each time the specification changes to reflect the new specification and to explain why something-X was chosen over something-Y. I think that by doing this the end-result will be less needless changes and a cleaner discussion platform for debates to happen on.

[M2Ys4U]

IMHO, 2 > 1 > 3 for the options.

I don't think public logging of the channel is that much of an issue - it's a public channel and the vast majority of things said in there is IRCv3 related.

[DarthGandalf]

:+1: for logging. Not sure what exactly you mean by grep though. Search box? Sure. Who needs plain txt these days? But then where is its “con” coming from?

[TheSaunders]

The idea for the second one was to do something like:

1. Log everything from #IRCv3 and then have a script that would do grep -A50 -B50 'term' where 'term' would be an issue.
2. Tag all of the lines returned with the 'term' that was grepped for
3. Have a website with all the 'terms' we have and allow users to click on them to read all the lines relating to the term they clicked.

But yes, it would likely be a bit better if the website just had a search function, I think that would get resource intensive for long logs though.

[ghost]

1. Put it on a root (e.g. logs.ircv3.org, assuming we can arrange for that)
2. Split it by day.
3. Use Google or another search engine which supports site: searches.

No need for us to write a log-search feature when search engines exist.

[kythyria]

@Aerdan Mostly true, but Google's output is formatted for "it's in this page somewhere" being good enough: wanting to find the page rather than the exact line. This may or may not be an issue.

@TheSaunders I can actually think of a way to reduce it to the cost of formatting a slightly augmented logfile and additional disk space for the results of each prebaked search, plus a cron job, but avoiding both races and the need to reread the entire result file each time is tricky.

[ghost]

@kythyria All browsers worth using have the ability to search within a page, so IMO this is a nonissue.

[TheSaunders]

@Aerdan Attempting to load months of text just so you can ctrl-f to search for text regarding an issue would not only be a waste of bandwidth but it would lag the browser considerably.

[ElementalAlchemist]

Combining Google's site: search with a reasonable split length (say, one day = one file) makes it not really that big of a deal.

Putting months and months of logs in one file would be dumb, and I'm pretty sure they know that.

[DarthGandalf]

When updating an issue, add a link to logs of discussion => the website hosting logs needs the ability to make a link to line number, similar to github