Enhancement: Finalize certain IOCCC terms and harmonize the repo to their use

[lcn2]

The IOCCC uses a number of terms, some of which have applied inconsistently.

TODO

• [x] Enumerate the IOCCC terms this issue will focus on

See comment 1930794508

• [x] Determine the short form of the above IOCCC terms

• Author

• Entry

• Submission

• [x] Suggest possible longer forms of the IOCCC short form terms

• [x] Create a FAQ entry for each IOCCC term

See also comment 1944209435.

• [x] Modify, if needed, directory and file names to use IOCCC short form terms

• [x] Update all IOCCC documentation to refer to the IOCCC terms (both short and longer forms)

• [x] Modify, if needed, all entry and year level README.md files if needed, to use IOCCC terms consistently in both the short and longer forms

• [x] Update source for for all IOCCC tools to refer to the IOCCC terms (both short and longer forms)

IOCCC term needs

The IOCCC has a need to use several terms. For example:

The IOCCC often refers to a directory of something that won the IOCCC (or is about to be announced as a new IOCCC entry that won the IOCCC).

The IOCCC often refers to author(s) of something that won the IOCCC (or is about to be announced as new author of a new IOCCC winning entry).

The IOCCC often refers something that has been submitted to the IOCCC judges while a new IOCCC is open for submissions, that may or may not win.

There might be other terms, that this issue needs to cover.

NOTE: We are using vague phrases because we are not presuming that the terms we have used in the past, even those terms used inconsistently, must continue to be used.

IMPORTANT NOTE: This issue is NOT about creating an exhaustive IOCCC glossary. This issue is ONLY CONCERNS ABOUT TERMS RELATED TO LONG STANDING PRACTICES.

Long-standing IOCCC practices

The IOCCC has a long-standing practice of ONLY RECOGNIZING THINGS THAT HAVE WON THE IOCCC as well as a long-standing practice of NOT RECOGNIZING THINGS THAT DO NOT WIN THE IOCCC. This in part because the only thing gained by a "win" is recognition. So, when we refer to something that won the IOCCC (or is about to be announced as a new IOCCC winning entry), we need a term that refers only to something that has won the IOCCC and NOT to something that did not win.

The IOCCC has a long-standing practice of NOT REVEALING THE NUMBER OF THINGS WERE SUBMITTED TO THE IOCCC JUDGES because that number includes both things that HAVE WON THE IOCCC as well as things that DID NOT WIN THE IOCCC. See the previous paragraph for one of the explanations as to why.

The IOCCC has a long-standing practice of announcing something that won the IOCCC, alongside the who is the author(s) of something that won the IOCCC. The directory structure is of years containing things that won the IOCCC. Within those things that won the IOCCC we indicate who is the author(s) of the something that won the IOCCC. In particular, things win the IOCCC and people are authors of things win the IOCCC.

The IOCCC has a long-standing practice of NOT KNOWING WHO IS THE AUTHOR of something that has been submitted to the IOCCC judges until the IOCCC judges determine that the something that won the IOCCC. This practice derives the judging process to the extent where something that has been submitted to the IOCCC judges is anonymous. And in keeping with the other practices mentioned above, the IOCCC only refers to author(s) of something that won the IOCCC (along with the IOCCC judges), and never to someone who may have submitted something to the IOCCC.

Unfortunately, due to the history of the IOCCC, there are years for which the IOCCC is not held. And while the purpose of this repo, the mkiocccentry tool set, the IOCCC submission server, the IOCCC registration process are being designed to make it easy for a new IOCCC to be held every year, we nevertheless do not plan to hold more the one IOCCC per 12-month calendar year.

Short and Long forms of a term

For every term that this issue addresses, there is a short form of that term. The short form of that term needs to be a single word.

One of the reasons for the short form being a single word is the short form may refer to a directory of filename where whitespace in the middle of the term is unwelcome.

For every term that this issue addresses, we assume that we will have a longer form of the same term.

One of the reasons for needing longer form is when the term needs to be used in a sentence (e.g., documentation, perhaps even man pages, tool prompts, FAQs, web pages, etc.). Another reason for needing longer form is when converting context to someone not familiar with IOCCC practices. There might even be more than one longer form of a term.

We recommend that the *short form* of a term be determined first. From there longer form** term(s), if needed, should become obvious.

[lcn2]

Suggestions for the singular short form IOCCC terms this issue needs to address:

For something that won the IOCCC (or is about to be announced as a new IOCCC winner):

0. winner

For author(s) of something that won the IOCCC (or is about to be announced as new author of a new IOCCC winner):

1. author

For something that has been submitted to the IOCCC judges while a new IOCCC is open for submissions, that may or may not win:

2. entry

We are not sure if this issue needs to cover any other terms.

We are not locked into the above singular short form terms.

[xexyl]

Suggestions for the singular short form IOCCC terms this issue needs to address:

For something that won the IOCCC (or is about to be announced as a new IOCCC winner):

0. winner

I still find this too ambiguous. But as a single word I can't think of a better term unless 'entry'. But that could be a lost entry (as below) too so it's not right either: that's also ambiguous. if we could have two words instead it'd be easier. Winner is a person, not what wins. Well okay: it can be a thing but it's ambiguous because it also suggests a person (or in some cases more than one). But 'entry' is not ambiguous (in the context of a submission): it means lost entry or winning entry but add 'winning' to it and it becomes not ambiguous at all: it becomes entirely clear what is meant for the contest (only winning entries).

For author(s) of something that won the IOCCC (or is about to be announced as new author of a new IOCCC winner):

But this could also be lost entries: losing authors, in other words. Even so the contest only refers to winning authors and entries so this one does work. Winning author isn't needed because only winning entries are referred to. Thus 'author' works well as it doesn't matter if winning or losing since only winning entries are referred to.

1. author

For something that has been submitted to the IOCCC judges while a new IOCCC is open for submissions, that may or may not win:

I agree with this except that the above complicates this a bit .. see my above comments.

2. entry

This does suggest any entry: not just winning entry. That's why 'winning entry' would be ideal. If the contest did refer to lost entries it would be 'losing entry' (or entries). Having the modifier 'winning' removes all ambiguity and doubt.

We are not sure if this issue needs to cover any other terms.

For now this works well enough I think?

We are not locked into the above singular short form terms.

I think a minor change would be good for reasons I noted elsewhere. But we can discuss that here.

In any event please assign this to me.

[xexyl]

I noticed (tried to fix it a bit) I organised my reply a bit confusingly. Too tired to try and fix it further so I'll return to this another time. Afk now probably for a good while.

[lcn2]

Suggestions for the singular short form IOCCC terms this issue needs to address: For something that won the IOCCC (or is about to be announced as a new IOCCC winner):

0. winner

I still find this too ambiguous. But as a single word I can't think of a better term unless 'entry'. But that could be a lost entry (as below) too so it's not right either: that's also ambiguous. if we could have two words instead it'd be easier. Winner is a person, not what wins. Well okay: it can be a thing but it's ambiguous because it also suggests a person (or in some cases more than one). But 'entry' is not ambiguous (in the context of a submission): it means lost entry or winning entry but add 'winning' to it and it becomes not ambiguous at all: it becomes entirely clear what is meant for the contest (only winning entries).

Understood on the concern expressed above about "winner" being "too ambiguous". Your point has merit.

For author(s) of something that won the IOCCC (or is about to be announced as new author of a new IOCCC winner):

But this could also be lost entries: losing authors, in other words. Even so the contest only refers to winning authors and entries so this one does work. Winning author isn't needed because only winning entries are referred to. Thus 'author' works well as it doesn't matter if winning or losing since only winning entries are referred to.

1. author

For something that has been submitted to the IOCCC judges while a new IOCCC is open for submissions, that may or may not win:

I agree with this except that the above complicates this a bit .. see my above comments.

As the IOCCC does not know, nor refer to anyone who submitted something that did not win the IOCCC, an "author" who did not win is never used. Therefore the complication mentioned above is not an important issue to the IOCCC.

2. entry

This does suggest any entry: not just winning entry. That's why 'winning entry' would be ideal. If the contest did refer to lost entries it would be 'losing entry' (or entries). Having the modifier 'winning' removes all ambiguity and doubt.

The short form of the term MUST be a single word, so while "winning entry" might be useful for the "longer form", it CANNOT be the short form.

We are not sure if this issue needs to cover any other terms.

For now this works well enough I think?

We agree.

We are not locked into the above singular short form terms.

I think a minor change would be good for reasons I noted elsewhere. But we can discuss that here.

In any event please assign this to me.

Done.

[xexyl]

I will reply to the above later today I hope. I am going to try and sleep again. Hope I can as I have been awake since before 2 :(

I just opened a pull request and I have some other changes to make (and already made) so I'll at least get some things in today but as far as this issue I guess we won't solve it today anyway. Maybe I can tackle other issues with 3 too.

[xexyl]

Suggestions for the singular short form IOCCC terms this issue needs to address: For something that won the IOCCC (or is about to be announced as a new IOCCC winner):

0. winner

I still find this too ambiguous. But as a single word I can't think of a better term unless 'entry'. But that could be a lost entry (as below) too so it's not right either: that's also ambiguous. if we could have two words instead it'd be easier. Winner is a person, not what wins. Well okay: it can be a thing but it's ambiguous because it also suggests a person (or in some cases more than one). But 'entry' is not ambiguous (in the context of a submission): it means lost entry or winning entry but add 'winning' to it and it becomes not ambiguous at all: it becomes entirely clear what is meant for the contest (only winning entries).

Understood on the concern expressed above about "winner" being "too ambiguous". Your point has merit.

Yes but if we must use a single word what can it be? Author seems appropriate instead of winner. Could we then have entry instead of winning entry and instead of winner have author? Do we need more than those two?

For author(s) of something that won the IOCCC (or is about to be announced as new author of a new IOCCC winner):

But this could also be lost entries: losing authors, in other words. Even so the contest only refers to winning authors and entries so this one does work. Winning author isn't needed because only winning entries are referred to. Thus 'author' works well as it doesn't matter if winning or losing since only winning entries are referred to.

1. author

For something that has been submitted to the IOCCC judges while a new IOCCC is open for submissions, that may or may not win:

I agree with this except that the above complicates this a bit .. see my above comments.

As the IOCCC does not know, nor refer to anyone who submitted something that did not win the IOCCC, an "author" who did not win is never used. Therefore the complication mentioned above is not an important issue to the IOCCC.

True. See above.

2. entry

This does suggest any entry: not just winning entry. That's why 'winning entry' would be ideal. If the contest did refer to lost entries it would be 'losing entry' (or entries). Having the modifier 'winning' removes all ambiguity and doubt.

The short form of the term MUST be a single word, so while "winning entry" might be useful for the "longer form", it CANNOT be the short form.

Why must it be a single word? That complicates the solution. Or maybe it doesn't. See my thoughts below. if we can get away with only two terms to decide it would work:

• author for the authors of winning entries
• entry for winning entries

Okay I see a third word. What about submissions or something that has been submitted (the third in the list)?

We are not sure if this issue needs to cover any other terms.

For now this works well enough I think?

We agree.

Figured as much. Good we're on the same page. Or line?

We are not locked into the above singular short form terms.

I think a minor change would be good for reasons I noted elsewhere. But we can discuss that here. In any event please assign this to me.

Done.

Thanks.

So to recap my suggestions / thoughts:

• author
• entry
• submission

Will those work?

[lcn2]

So to recap my suggestions / thoughts:

author entry submission

Will those work?

We think so.

UPDATE 0b

The TODO at the top of this issue has been updated.

IOCCC terms

The term author(s) will apply to the person(s) who wrote an entry that has won an IOCCC.

A submission is something sent to the IOCCC judges for consideration while the IOCCC is open. As a submission is judged anonymously, the term author does NOT apply to a submission. Only those submissions that win the IOCCC turn into an entry, and those who submitted the winning entry become an author (if they are new to the IOCCC) or have their list of winning entryies updated.

It has been decided to limit this issue to the 3 terms mentioned above.

Impact of this decision

The above will require some changes in documentation, program comments, program prompts, and the FAQ.

NOTE: The scope of these changes includes BOTH both this repo and the [mkiocccentry repo].

For example, the term winner previously was applied to the contents of a "YYYY/dir" directory. Now we will use the term entry for such a "YYYY/dir" directory. This is probably the most impacting change of terms. And the JSON file .winner.json will need to be renamed .entey.json.

The term author was often used in the past, so there is probably fewer things that need to be changed as a result for the author term.

The term submission was sometimes used as the past, but so was other terms (such as entry, program, etc.). There will be some things that need to be updated as a result of using the submission term.

[xexyl]

So to recap my suggestions / thoughts: author entry submission Will those work?

We think so.

Great. So we can discuss in more details another day. Best wishes with the eye dilation! Hope all is well.

[lcn2]

Given the corrected UPDATE 0a above, the next thing is to agree on longer forms of the 3 terms.

It would be best to do a a brief scan of both this repo and the mkiocccentry repo for places where these 3 terms would apply. While such a brief scan does not need to be posted here: such a brief scan would be helpful in becoming familiar with the ways that these 3 terms are used. That in turn will be helpful to understand the longer forms of these terms.

NOTE: Scan doesn't mean to edit: editing comes later.

TL;DR understand in both this repo and the [mkiocccentry repo] as to how these terms apply BEFORE suggesting longer form variants of the 3 short form terms.

Doing the above first before the FAQ is updated will also be important.

[xexyl]

I will look back at the comment and your suggestions tomorrow morning. If by chance I fail to do so please remind me.

[xexyl]

So to recap my suggestions / thoughts: author entry submission Will those work?

We think so.

UPDATE 0b

The TODO at the top of this issue has been updated.

I presume that since the terms have to be decided first I can check this later. In any event I am afraid I am too tired to focus much on details now so I'm just going through this comment to make sure I do follow it. Then when I can focus more I can do the actual scanning of both repos.

IOCCC terms

I'm glad you agree to the changes. Thanks! It makes it much more clear.

The term author(s) will apply to the person(s) who wrote an entry that has won an IOCCC.

Now this one has been used before so am I correct in saying that this does not have to be changed? Or can you think of cases where it was used differently?

A submission is something sent to the IOCCC judges for consideration while the IOCCC is open. As a submission is judged anonymously, the term author does NOT apply to a submission. Only those submissions that win the IOCCC turn into an entry, and those who submitted the winning entry become an author (if they are new to the IOCCC) or have their list of winning entryies updated.

This makes sense too. But did you have a term I should look for when it comes to 'submission'? I guess we did discuss this but I can't remember and I want to be sure I have this right. Naturally author only matters for winning entries and submission refers to what MIGHT become an entry or otherwise is torn to bits.

It has been decided to limit this issue to the 3 terms mentioned above.

Impact of this decision

The above will require some changes in documentation, program comments, program prompts, and the FAQ.

That makes sense.

NOTE: The scope of these changes includes BOTH both this repo and the [mkiocccentry repo].

I certainly would not consider changing any until everything has been decided! But thanks for the reminder just in case.

For example, the term winner previously was applied to the contents of a "YYYY/dir" directory. Now we will use the term entry for such a "YYYY/dir" directory. This is probably the most impacting change of terms. And the JSON file .winner.json will need to be renamed .entey.json.

Hopefully .entry.json :-). And that indeed will be an example (I think) where both documentation and code will have to be updated. Certainly documentation and I'm sure some of the scripts in bin/ as well as possibly other code (other repo not so sure .. yet anyway).

The term author was often used in the past, so there is probably fewer things that need to be changed as a result for the author term.

I hope so.

The term submission was sometimes used as the past, but so was other terms (such as entry, program, etc.). There will be some things that need to be updated as a result of using the submission term.

Hmm ... yes so that brings up the question of: what terms do you think I should look for? Here are those I can think of right now:

• submission
• entry (and entries)
• author (obviously authors but searching for author will do that)
• winner (obviously winners but searching for winner will do that)
• (probably?) winning
• program (maybe prog too?) (programs would be found by program - what about progs? I don't think it was used but maybe?)
• other terms (what are they?)

Final thoughts for the time being

As for the longer terms do we have any constraints in length? Do you have a good example for both short and long term use for each of the three terms? That might be useful.

I'll offer that I changed in many cases 'winner' to 'winning entry' so that might or might not be useful for a longer term. But perhaps that is now not a good term at all. I could see it that way too. I'm not suggesting it either way btw: just wanted to bring up an example of the ambiguity that I saw at first and tried to fix. This one particularly happened in the YYYY/README.md files that I have gone through (which I see now cannot be touched until after this issue is resolved - or am I wrong there?).

[lcn2]

The term author(s) will apply to the person(s) who wrote an entry that has won an IOCCC.

Now this one has been used before so am I correct in saying that this does not have to be changed? Or can you think of cases where it was used differently?

Probably not best to think about it but instead complete scan code, comments, filenames, documentation in of both this repo and the mkiocccentry repo for places where these 3 terms would apply, regardless of how they may be used now. Therefore we will not answer the question above as the complete scan (and not "think of cases where it was used differently") is the a key part of the work of this issue.

We have no idea how consistent term use was in the past, other than to speculate that terms were likely used inconsistently.

A submission is something sent to the IOCCC judges for consideration while the IOCCC is open. As a submission is judged anonymously, the term author does NOT apply to a submission. Only those submissions that win the IOCCC turn into an entry, and those who submitted the winning entry become an author (if they are new to the IOCCC) or have their list of winning entryies updated.

This makes sense too. But did you have a term I should look for when it comes to 'submission'? I guess we did discuss this but I can't remember and I want to be sure I have this right. Naturally author only matters for winning entries and submission refers to what MIGHT become an entry or otherwise is torn to bits.

See above.

We have no idea how consistent term use was in the past, other than to speculate that terms were likely used inconsistently.

UPDATE 0a

The term submission was sometimes used as the past, but so was other terms (such as entry, program, etc.). There will be some things that need to be updated as a result of using the submission term.

Hmm ... yes so that brings up the question of: what terms do you think I should look for? Here are those I can think of right now:

• submission
• entry (and entries)
• author (obviously authors but searching for author will do that)
• winner (obviously winners but searching for winner will do that)
• (probably?) winning
• program (maybe prog too?) (programs would be found by program - what about progs? I don't think it was used but maybe?)
• other terms (what are they?)

We have no idea other that vague guesses that are not very useful. A complete scan code, comments, filenames, documentation in of both this repo and the mkiocccentry repo for places where these 3 terms would apply, regardless of how they may be used now. Therefore we will not answer the question above as the complete scan (and not "think of cases where it was used differently") is the a key part of the work of this issue.

When a filename that relates to one of the terms needs to change, the corresponding code needs to be modified and tested. When a filename that relates a markdown file needs to change, the corresponding HTML page that will be used by browsers needs to change as well. Links to such files will need to change.

One particular question to ask is what should be done with the HTML page: winners.html. The winners.html page is highly linked around the internet. However, given the terms for which this issue is concerned, such a web page should be called author.html. Here the use of the singular short form of the term applies. Do deal with those external pages that link to the official IOCCC winners.html page, the existing winners.html file should turn into a static redirect from winners.html to author.html as in:

<meta http-equiv="Refresh" content="0; url=author.html">

Final thoughts for the time being

As for the longer terms do we have any constraints in length? Do you have a good example for both short and long term use for each of the three terms? That might be useful.

As for the length of the "longer term" forms, it depends on context, grammar, and sentence structure.

You will know it when you see it. For example if you see stuff related to someone who has won the IOCCC, and the "short form" term author is awkward in a sentence, some additional works (adjectives and other qualifier words) might be useful as a "longer form" term. Again, it depends on "context, grammar, and sentence structure".

I'll offer that I changed in many cases 'winner' to 'winning entry' so that might or might not be useful for a longer term. But perhaps that is now not a good term at all. I could see it that way too. I'm not suggesting it either way btw: just wanted to bring up an example of the ambiguity that I saw at first and tried to fix. This one particularly happened in the YYYY/README.md files that I have gone through (which I see now cannot be touched until after this issue is resolved - or am I wrong there?).

Good point. Again, "context, grammar, and sentence structure" are key for specific cases. If the "short form" of the term entry work, find. However sentence flow and clarify might suggest some additional words may be useful.

Also plural forms of one of the 3 terms may be needed in "documentation, program comments, program prompts, and the FAQ"

UPDATE 1

TL:DR :-)

There is NOT a simple answer to what words need to be changed. There isn't a simple sgit(1) command that will resolve this issue. If there was, then such commands would have been performed already and this issue would not have been created.

One must scan both this repo and the mkiocccentry repo for cases where one of the 3 terms apply. This scan includes code as well as documentation and filenames.

For filenames and code excluding comments, the singular "short form" relating to the 3 terms is strongly preferred. Consistency and "grep-ability" is very important. Code changes and testing will be needed. And there is a special case where the old winners.html page needs to redirect to a new author.html page.

For comments in code, a combination of singular "short form"(s) or plural / "longer form"(s) of relating to the 3 terms is recommended.

For other documentation where the 3 terms apply, with a priority on grammar and readability, a combination of singular "short form"(s) or plural / "longer form"(s) of relating to the 3 terms is recommended.

Where it is reasonable, limiting the variety of "longer form" term use is recommended.

[lcn2]

When to use singular short form

When dealing with a filenames or programs variables, use of the singular "short form" is needed.

If one were to grep for author in code (C, shell, awk, sed, etc.) one should be able to easily find cases where the term applies. Making up an fake example here:

    char *winner_full_name;        /* full name of a winner */

might need to be changed to:

    char *author_full_name;        /* full name of winning IOCCC author */

Use of the singular "short form" of the 3 terms should be strongly preferred in actual code (excluding code comments), and filenames. So, for another fake example:

    int total_entries = 0;    /* total number of entries in a given year */   <<== Don't do this
...
    int entry_count = 0;      /* total number of entries in a given year */   <<== Do this

A similar case applies to function names as well.

Consistency in use of the singular "short form" terms in actual code (excluding code comments), and filenames is important.

On the variety of "Longer form" terms

However, documentation (README.md files, man pages, FAQ, and comments in code, etc.) may read better and make better sue of grammar, depending on the context, if various plural "short form" terms OR "longer form" terms are used.

If there was some level of consistency of the use of "longer form" terms in documentation (README.md files, man pages, FAQ, and comments in code, etc.), as a limited the variety of "longer form"(s) of a given term would be nice. Moreover, a more consistent use of a limited set of "longer form" terms would help the reader recognize the context dependent use of one of the 3 terms for which this issue is now focused on.

Nevertheless, the readability and grammar of the documentation is more important than simply limiting the number of different "longer form"(s) of a term.

Thus, for another fake example:

The IOCCC judges congratulate the authors of the this year's IOCCC entries. 
Both the new IOCCC authors and those IOCCC authors who won the IOCCC
before submitted well above average winning entries to this IOCCC.

Code comments vs. grammar

Now, the case of code comments are a middle ground case. Especially when dealing with "inline / on the same line style comments". In code where a very long comment is not wanted, a verbose and perhaps better grammar is not wanted. Consider this fake example where terms are used:

    bool known_author;    /* true ==> If the IOCCC author has a file in the author directory prior to the current IOCCC contest that is being judged, and before the pre-announced entry has been pushed via a git commit to the official IOCCC winning repo.  false ==> The IOCCC author has not had a submission that won the IOCCC prior to the current IOCCC that is being judged,  and thus the pre-announced entry has been pushed for public viewing, via a git commit, to the official IOCCC winning repo by unanimous agreement of all of the IOCCC judges. */   <<== Don't do this  :-)
...
    bool known_author;    /* true => has author JSON file, false ==> new author */   <<== Do this

Even in multi-line comments where terms are used:

# We have found a new IOCCC winning entry.  This new IOCCC winning entry may have been publish
# before the time that this code is run, or it may be winning IOCCC entry that has yet to be published
# of the IOCCC judges, using a git commit command, onto the official winning IOCCC repo and thus
# is not yet known to the general public who might be, at this very moment, refreshing their browsers
# every few seconds.   We add this winning IOCCC entry to the count, regardless of if this IOCCC winning
# entry is known to the general public. <<== Don't do this  :-)
#
((++ENTRY_COUNT))
...
# Count the IOCCC entry (previously published or about to be published)
# 
# Continue to count entries until current phase is complete.    <<== Do this
#
((++ENTRY_COUNT))

[xexyl]

A lot to parse and more than I am capable of doing atm. But I'll reply to one thing anyway ... the rest will have to wait until later which might or might not be today. I'm afraid it might not but we'll see.

One particular question to ask is what should be done with the HTML page: winners.html. The winners.html page is highly linked around the internet. However, given the terms for which this issue is concerned, such a web page should be called author.html. Here the use of the singular short form of the term applies. Do deal with those external pages that link to the official IOCCC winners.html page, the existing winners.html file should turn into a static redirect from winners.html to author.html as in:

<meta http-equiv="Refresh" content="0; url=author.html">

That is a possibility but I think in this case winners.html still would work fine. Why? Because it's not referring to an entry but the authors and winner and author can be used synonymously I think. In most cases (I guess?) it might not be good to do that but in some cases it would be fine I think esp if it helps keep things sane across the Internet. But certainly a redirect would solve the problem. if I may though I'd say that authors.html (plural) would be better than author.html (singular): since it's not a single author but many.

Final thoughts for the time being

As for the longer terms do we have any constraints in length? Do you have a good example for both short and long term use for each of the three terms? That might be useful.

As for the length of the "longer term" forms, it depends on context, grammar, and sentence structure.

You will know it when you see it. For example if you see stuff related to someone who has won the IOCCC, and the "short form" term author is awkward in a sentence, some additional works (adjectives and other qualifier words) might be useful as a "longer form" term. Again, it depends on "context, grammar, and sentence structure".

I'll offer that I changed in many cases 'winner' to 'winning entry' so that might or might not be useful for a longer term. But perhaps that is now not a good term at all. I could see it that way too. I'm not suggesting it either way btw: just wanted to bring up an example of the ambiguity that I saw at first and tried to fix. This one particularly happened in the YYYY/README.md files that I have gone through (which I see now cannot be touched until after this issue is resolved - or am I wrong there?).

Good point. Again, "context, grammar, and sentence structure" are key for specific cases. If the "short form" of the term entry work, find. However sentence flow and clarify might suggest some additional words may be useful. Okay I'll reply to a bit more.. then I must stop I'm afraid.

Sure context/grammar/structure is useful but I'm not even sure what to look for. I guess grep(1) will be our friend (or more likely git grep) but there is a huge amount of code and documentation plus looking at the old website too. There are guidelines and rules also that might need to be looked at. So it would be helpful if we had terms to look for. Otherwise how do I prioritise this over other things? How do I proceed?

Also plural forms of one of the 3 terms may be needed in "documentation, program comments, program prompts, and the FAQ"

Of course (like those I put in parentheses).

UPDATE 1

TL:DR :-)

There is NOT a simple answer to what words need to be changed. There isn't a simple sgit(1) command that will resolve this issue. If there was, then such commands would have been performed already and this issue would not have been created.

Well not a simple sgit(1) command but it can be useful in a lot of cases at least. But in others it might not be. I'm less concerned about that though: I'm more concerned about finding all the terms and then also even if we have a list of terms to look for how do we know there aren't others somewhere that could be missed and cause problems when they are seen?

One must scan both this repo and the mkiocccentry repo for cases where one of the 3 terms apply. This scan includes code as well as documentation and filenames.

How do you suggest we scan them? Okay filenames are one thing but the rest is not as clear: except for some keywords of course which can be decided upon here. I think probably better to come up with a list to look at before trying. Even so as mentioned above it won't mean that we'll catch everything and there is a lot to go through.

Since part of this issue is a dependency on part of issue 3 that's also a problem though since that's only (I think or primarily: at least in the todo file) in the YYYY/README.md files that can be quickly changed later after these terms are decided upon.

For filenames and code excluding comments, the singular "short form" relating to the 3 terms is strongly preferred. Consistency and "grep-ability" is very important. Code changes and testing will be needed. And there is a special case where the old winners.html page needs to redirect to a new author.html page.

Speaking of grep: as I thought .. but any suggested terms besides what I already mentioned? I think you said you're not even sure but do you think I should start out with what I did suggest?

For comments in code, a combination of singular "short form"(s) or plural / "longer form"(s) of relating to the 3 terms is recommended.

Makes sense.

For other documentation where the 3 terms apply, with a priority on grammar and readability, a combination of singular "short form"(s) or plural / "longer form"(s) of relating to the 3 terms is recommended.

Okay.

Where it is reasonable, limiting the variety of "longer form" term use is recommended.

Okay.

Well I replied to more than I thought. Not sure if what I skipped is in need of a reply or not but I can look at that later. Going afk again soon .. very unlikely I can sleep again but I hope to rest a bit. Not sleeping in again :( and very tired ... kind of difficult night though certainly there have been many worse ones.

[xexyl]

I think (at least at this hour) that comment 1932737721 makes sense and I more or less agree with it. I'll have to look back at it another time to be sure. I think though that it's also less important AT THIS POINT. First we have to come up with the proper terms and then we can consider HOW to update everything.

Perhaps you could put that comment in the todo list? That would be helpful so it's easier to find later. Thanks.

[lcn2]

As per commit aedb0172239504fb14249a23069e91367b10b58b (see comment 1937947954), the bin/ and tmp/ tools in the temp-test-ioccc repo have been updated to reflect that winner is now entry.

While the changes introduced by commit aedb0172239504fb14249a23069e91367b10b58b were extensive, there may have been things that were missed.

UPDATE 0

More instances of winner changes to entry in commit 16cc268c2aadd4254f044cbaaf6e34b330cc2141.

[xexyl]

As per commit aedb017 (see comment 1937947954), the bin/ and tmp/ tools in the temp-test-ioccc repo have been updated to reflect that winner is now entry.

While the changes introduced by commit aedb017 were extensive, there may have been things that were missed.

UPDATE 0

More instances of winner changes to entry in commit 16cc268.

I'll have to look at these things another day too but I'd be happy to check these things too. Did you update anything mkiocccentry repo? If not what would have to change? I guess we might want to wait until after everything looks good here before we do that though?

[xexyl]

I believe I replied to everything except the things I have to look at another day. If there's anything I missed though please let me know. I'll be doing other things for the rest of the day. Too tired to focus on anything here. I hope tomorrow I'll be able to do more hopefully including looking at your comments in more detail.

[lcn2]

Did you update anything mkiocccentry repo? If not what would have to change?

No changes were made and don't know which is why this issue exists. 😁

UPDATE 0a

An equivalent issue needs to be opened up in the mkiocccentry repo.

Equivalent in terms of changing the terms and defined in this issue, not in terms of defining terms. 😁

Puns aside: We need a new issue for the mkiocccentry repo to change any text, prompts, code, code comments, man pages and other documentation to reflect the use of the 3 terms that have been declared by this issue.

[xexyl]

Did you update anything mkiocccentry repo? If not what would have to change?

No changes were made and don't know which is why this issue exists. 😁

I thought the issue was more of coming up with the terms. But then again I guess the other point is the NeXTSTEP so that does make sense.

[xexyl]

Did you update anything mkiocccentry repo? If not what would have to change?

No changes were made and don't know which is why this issue exists. 😁

I thought the issue was more of coming up with the terms. But then again I guess the other point is the NeXTSTEP so that does make sense.

I obviously couldn't resist the opportunity for the pun, whatever one might or might not think of NeXTSTEP.

[lcn2]

Did you update anything mkiocccentry repo? If not what would have to change?

No changes were made and don't know which is why this issue exists. 😁

I thought the issue was more of coming up with the terms. But then again I guess the other point is the NeXTSTEP so that does make sense.

See UPDATE 0a above.

Also please reread the TODO list at the top of this issue. Most of the bullet points relate to modifying things once decided.

[xexyl]

As for references to winner ....

git grep 'winner'

might be useful.

Of course it'd be best to keep the winners.html file as that name. But things like:

--

1984/anonymous/Makefile:11:# first check this URL for a list of known bugs and (mis)features of IOCCC winners: 1985/Makefile:41:# IOCCC winners 1985/README.md:9:avoid another 1984 style winner (1984/mullender). 1985/applin/.entry.json:3: "winner_JSON_format_version" : "1.1 2024-02-11", 1985/applin/.entry.json:7: "winner_id" : "1985_applin",

--

might need to be changed to entries/entry? Want me to change these references? Can do easily with sgit(1) if you want. Not sure if I would do that today or not: might be wise not to but I'd have to see how I feel. But I could easily do it and I'm sure that would be of some help.

Just let me know and I'll go from there. Anyway doing other things now, things that require no real thinking. I believe I'll be reading a book I've read about 217 times. Well okay maybe minus 200 and in the middle of the 18th. I need not mention the title for you to know! But I'm not even sure if I can do that. It was a difficult night and I'm just trying to recuperate from yesterday. Totally worth it of course.

So I think that if I do the task (if you want me to do it) I'll wait until tomorrow. But the question is do you want me to do these changes? Let me know. Thanks!

[xexyl]

Did you update anything mkiocccentry repo? If not what would have to change?

No changes were made and don't know which is why this issue exists. 😁

UPDATE 0a

An equivalent issue needs to be opened up in the mkiocccentry repo.

Equivalent in terms of changing the terms and defined in this issue, not in terms of defining terms. 😁

Puns aside: We need a new issue for the mkiocccentry repo to change any text, prompts, code, code comments, man pages and other documentation to reflect the use of the 3 terms that have been declared by this issue.

Of course .. still had to do it! My guess is that that issue shouldn't be opened until after this one is resolved?

[lcn2]

As for references to winner ....

git grep 'winner'

might be useful.

Of course it'd be best to keep the winners.html file as that name.

As per commit aedb0172239504fb14249a23069e91367b10b58b the winners.html file is now a auto-redirect page to the new authors.html page.

But things like:

--

1984/anonymous/Makefile:11:# first check this URL for a list of known bugs and (mis)features of IOCCC winners: 1985/Makefile:41:# IOCCC winners 1985/README.md:9:avoid another 1984 style winner (1984/mullender). 1985/applin/.entry.json:3: "winner_JSON_format_version" : "1.1 2024-02-11", 1985/applin/.entry.json:7: "winner_id" : "1985_applin",

--

might need to be changed to entries/entry?

Yes, the _winnerid JSON member name needs to become _entryid. And _winner_JSON_formatversion needs to become _entry_JSON_formatversion.

Other code in tmp and bin already expects that this will be changed, but that code needs to be checked.

Same things for Makefiles, and entry level README.md files: those need to be updated.

Want me to change these references? Can do easily with sgit(1) if you want.

Yes please.

Not sure if I would do that today or not: might be wise not to but I'd have to see how I feel. But I could easily do it and I'm sure that would be of some help.

Scanning over code and other files where the 3 terms apply needs to be done. In some cases with comments, code and variables, careful checking and editing needs to happen (as we found with commit 0cd6385657bb57eff5e98d93439ed79f88547e59. commit 23d3e5fbb5f67248daf7f20ebcc63e52d23dc203, commit 16cc268c2aadd4254f044cbaaf6e34b330cc2141, etc.).

Just let me know and I'll go from there. Anyway doing other things now, things that require no real thinking.

As this is a Top Priority item, help is appreciated.

I believe I'll be reading a book I've read about 217 times. Well okay maybe minus 200 and in the middle of the 18th. I need not mention the title for you to know! But I'm not even sure if I can do that. It was a difficult night and I'm just trying to recuperate from yesterday. Totally worth it of course.

🤓

So I think that if I do the task (if you want me to do it) I'll wait until tomorrow. But the question is do you want me to do these changes? Let me know. Thanks!

Yes please.

[lcn2]

Did you update anything mkiocccentry repo? If not what would have to change?

No changes were made and don't know which is why this issue exists. 😁

UPDATE 0a

An equivalent issue needs to be opened up in the mkiocccentry repo. Equivalent in terms of changing the terms and defined in this issue, not in terms of defining terms. 😁 Puns aside: We need a new issue for the mkiocccentry repo to change any text, prompts, code, code comments, man pages and other documentation to reflect the use of the 3 terms that have been declared by this issue.

Of course .. still had to do it!

😀

My guess is that that issue shouldn't be opened until after this one is resolved?

Well once the initial TODO related to determine the terms was done, the important decisions we make. Now an issue to modify stuff in the mkiocccenty needs to be opened and worked on. Please consider making such an issue.

UPDATE 0

Obviously, work on such a new mkiocccenty issue is of lower priority. But it might be nice to at least create the new issue now.

[lcn2]

We believe we have addressed all of the current questions that still need answering at this time. If we've missed something or something else needs to be clarified, please ask again.

[xexyl]

As for references to winner ....

git grep 'winner'

might be useful.

Of course it'd be best to keep the winners.html file as that name.

As per commit aedb0172239504fb14249a23069e91367b10b58b the winners.html file is now a auto-redirect page to the new authors.html page.

But things like:

--

1984/anonymous/Makefile:11:# first check this URL for a list of known bugs and (mis)features of IOCCC winners: 1985/Makefile:41:# IOCCC winners 1985/README.md:9:avoid another 1984 style winner (1984/mullender). 1985/applin/.entry.json:3: "winner_JSON_format_version" : "1.1 2024-02-11", 1985/applin/.entry.json:7: "winner_id" : "1985_applin",

--

might need to be changed to entries/entry?

Yes, the _winnerid JSON member name needs to become _entryid. And _winner_JSON_formatversion needs to become _entry_JSON_formatversion.

Other code in tmp and bin already expects that this will be changed, but that code needs to be checked.

Same things for Makefiles, and entry level README.md files: those need to be updated.

Want me to change these references? Can do easily with sgit(1) if you want.

Yes please.

Not sure if I would do that today or not: might be wise not to but I'd have to see how I feel. But I could easily do it and I'm sure that would be of some help.

Scanning over code and other files where the 3 terms apply needs to be done. In some cases with comments, code and variables, careful checking and editing needs to happen (as we found with commit 0cd6385657bb57eff5e98d93439ed79f88547e59. commit 23d3e5fbb5f67248daf7f20ebcc63e52d23dc203, commit 16cc268c2aadd4254f044cbaaf6e34b330cc2141, etc.).

Just let me know and I'll go from there. Anyway doing other things now, things that require no real thinking.

As this is a Top Priority item, help is appreciated.

I believe I'll be reading a book I've read about 217 times. Well okay maybe minus 200 and in the middle of the 18th. I need not mention the title for you to know! But I'm not even sure if I can do that. It was a difficult night and I'm just trying to recuperate from yesterday. Totally worth it of course.

🤓

So I think that if I do the task (if you want me to do it) I'll wait until tomorrow. But the question is do you want me to do these changes? Let me know. Thanks!

Yes please.

I will do this tomorrow morning.

After that I will look at other comments and reply as necessary. After that we'll see. Maybe continue where I left off the other day.

I will be going to bed soon. Hope you have a great night.

[xexyl]

Did you update anything mkiocccentry repo? If not what would have to change?

No changes were made and don't know which is why this issue exists. 😁

UPDATE 0a

An equivalent issue needs to be opened up in the mkiocccentry repo. Equivalent in terms of changing the terms and defined in this issue, not in terms of defining terms. 😁 Puns aside: We need a new issue for the mkiocccentry repo to change any text, prompts, code, code comments, man pages and other documentation to reflect the use of the 3 terms that have been declared by this issue.

Of course .. still had to do it!

😀

My guess is that that issue shouldn't be opened until after this one is resolved?

Well once the initial TODO related to determine the terms was done, the important decisions we make. Now an issue to modify stuff in the mkiocccenty needs to be opened and worked on. Please consider making such an issue.

UPDATE 0

Obviously, work on such a new mkiocccenty issue is of lower priority. But it might be nice to at least create the new issue now.

Please let me know when you've done so just in case I don't see it. Maybe you already have and I missed it? Ah I see .. you want me to do it. I can do that but I'm not sure what to say just yet. Should it be something that refers to this issue and then adds that there are terms/phrases that are used in the repo (mkiocccentry repo) that should be updated too to match the ones used here? I might link to certain comments too.

Still I'll hold off on doing that unless you think we have indeed finalised all terms (short and long)? I'm going to take a shower soon and then hoping I can go back to sleep. When more awake I'll do the renaming of those fields/variables/whatever else. That'll probably be a while from now. I opened a small pull request a short bit ago: just typo fixes and comments updated in the top level Makefile plus aliased some rules (the names of course) to match the tools (names) they used.

[xexyl]

Huge update in the works with the name changes ... stay tuned.

[xexyl]

Huge update in the works with the name changes ... stay tuned.

Please see https://github.com/ioccc-src/temp-test-ioccc/pull/2208/commits/205fa25cedd798ae1a6d2fb8ddb156004fc84ed5 and https://github.com/ioccc-src/temp-test-ioccc/pull/2208/commits/c703a1ed671e94940069797fc1386c60301daee3.

Apologies on the size of the commit. That's actually why I stopped. I asked in that pull request for you to check git grep winner after the commits to see if I missed anything but saying it here too as this is the issue itself.

Please read the log of the first commit. If there's a way to test things better that would be great: just let me know and I'll be happy to do it. However I believe that I am done for the day. Just too tired. But I guess I did do a few good helpful things. Hopefully I'll feel up to doing a bit tomorrow but as you know it's a day where I might not want to.

I might add that if you have fun properties/things about 42 I'd love to hear them in that other issue (5 I guess it is)! Anyway hopefully these commits are a great start.

I bid you a good day!

[lcn2]

Regarding comment 19418166070:

Please do:

git grep winner

Will do.

and let me know what else you think might need to change.

OK.

Also was I supposed to check another word or more than one word?

We do not understand that last sentence.

[xexyl]

Regarding comment 19418166070:

Please do:

git grep winner

Will do.

and let me know what else you think might need to change.

OK.

Also was I supposed to check another word or more than one word?

We do not understand that last sentence.

I meant are there other words I should have changed?

[lcn2]

Regarding comment 19418166070:

Please do:

git grep winner

Will do.

and let me know what else you think might need to change.

OK.

Also was I supposed to check another word or more than one word?

We do not understand that last sentence.

I meant are there other words I should have changed?

We managed to sneak in commit 86b8c91b0d8e18e6f49a07d514ccdba43219e283 and commit b805203e6f27e08bb1e9d121d19d03ab30c508c0 during a lunch break (that might not happen again for a few days).

We changed winners to entries in inc/sidenav.default.html and then did a make www (after reordering to put the _form_entrytarball rule after _entryindex) as a quick way to eliminate a number of the cases where winners was found in web pages.

As git grep -l winners shows, and ignoring these cases:

• tmp/OLD_manifest/*
• winners.html
• archive/historic/*
• 1984/anonymous/README.md
• 1984/anonymous/index.html
• README.md
• tmp/*

We see that:

git grep winners 2>&1 | egrep -v 'tmp/|archive/historic|1984/anonymous'

shows a number of cases (probably most?) where winner[s] could and probably should be changed. Please review and change as you think best.

One thing we cannot change right now is the winner repo name. Doing that would not be wise at this time, if ever. So references to the winner repo name should remain. And it is probably not that bad as the term winner refers to both authors and entries. So yea, the winner repo name should probably not change.

[xexyl]

Regarding comment 19418166070:

Please do:

git grep winner

Will do.

and let me know what else you think might need to change.

OK.

Also was I supposed to check another word or more than one word?

We do not understand that last sentence.

I meant are there other words I should have changed?

We managed to sneak in commit 86b8c91 and commit b805203 during a lunch break (that might not happen again for a few days).

No worries there. I won't be doing much for a few days either as you know.

We changed winners to entries in inc/sidenav.default.html and then did a make www (after reordering to put the _form_entrytarball rule after _entryindex) as a quick way to eliminate a number of the cases where winners was found in web pages.

Thanks.

As git grep -l winners shows, and ignoring these cases:

• tmp/OLD_manifest/*
• winners.html
• archive/historic/*
• 1984/anonymous/README.md
• 1984/anonymous/index.html
• README.md
• tmp/*

We see that:

git grep winners 2>&1 | egrep -v 'tmp/|archive/historic|1984/anonymous'

shows a number of cases (probably most?) where winner[s] could and probably should be changed. Please review and change as you think best.

I'll look at this in the next few days I guess.

One thing we cannot change right now is the winner repo name. Doing that would not be wise at this time, if ever. So references to the winner repo name should remain. And it is probably not that bad as the term winner refers to both authors and entries. So yea, the winner repo name should probably not change.

Agreed. I don't think it should be changed at all either (at least at this point? .. but probably ever).

[xexyl]

.. shouldn't the reference to winner in rules and guidelines remain the same for historical purposes? Or do you want me to change those too?

Well anyway going for the night .. unsure if I'll do anything here tomorrow or not. Good night!

[lcn2]

.. shouldn't the reference to winner in rules and guidelines remain the same for historical purposes? Or do you want me to change those too?

Well anyway going for the night .. unsure if I'll do anything here tomorrow or not. Good night!

Can see it both ways: perhaps you are correct and that the historic rules and guidelines should be let alone?

[xexyl]

.. shouldn't the reference to winner in rules and guidelines remain the same for historical purposes? Or do you want me to change those too?

Well anyway going for the night .. unsure if I'll do anything here tomorrow or not. Good night!

Can see it both ways: perhaps you are correct and that the historic rules and guidelines should be let alone?

I see it both ways too. But something to consider: often enough authors have referred to the guidelines and rules. One entry writes out part of the guidelines too. Not at laptop right now to check but if it wrote part that uses those terms it would be no longer valid. That itself is reason enough to not do it.

HOWEVER .. it probably should be done in the top level README ? Maybe in that file though there should be a historical note about it. Since it's a significant part of the contest history perhaps you would like to do this part if you agree with me there?

I can look at the other places though. However right now not even at laptop and won't be for a bit.

I am feeling pretty good right now: managed to sleep in which is super useful for today: naturally!

I hope that I will be at laptop in an hour or 1.5 hours.

Hope you're sleeping well my good friend!

[xexyl]

Suggestion: the FAQ (after the terms have been finalised) should have a section about the IOCCC terms. This might include questions like what they each are and also how they changed over the years, why (maybe why) etc.

[lcn2]

.. shouldn't the reference to winner in rules and guidelines remain the same for historical purposes? Or do you want me to change those too? Well anyway going for the night .. unsure if I'll do anything here tomorrow or not. Good night!

Can see it both ways: perhaps you are correct and that the historic rules and guidelines should be let alone?

I see it both ways too. But something to consider: often enough authors have referred to the guidelines and rules. One entry writes out part of the guidelines too. Not at laptop right now to check but if it wrote part that uses those terms it would be no longer valid. That itself is reason enough to not do it.

Good points. Let us not change terms in these historic documents.

HOWEVER .. it probably should be done in the top level README ? Maybe in that file though there should be a historical note about it. Since it's a significant part of the contest history perhaps you would like to do this part if you agree with me there?

Yes, to both.

I can look at the other places though. However right now not even at laptop and won't be for a bit.

I am feeling pretty good right now: managed to sleep in which is super useful for today: naturally!

I hope that I will be at laptop in an hour or 1.5 hours.

Hope you're sleeping well my good friend!

Best wishes for a Happy and Fun birthday 🎉🎂🥳

[lcn2]

Suggestion: the FAQ (after the terms have been finalised) should have a section about the IOCCC terms. This might include questions like what they each are and also how they changed over the years, why (maybe why) etc.

Adding an FAQ has been in the TODO list above. We added an additional link to your comment.

[xexyl]

Suggestion: the FAQ (after the terms have been finalised) should have a section about the IOCCC terms. This might include questions like what they each are and also how they changed over the years, why (maybe why) etc.

Adding an FAQ has been in the TODO list above. We added an additional link to your comment.

Thanks.

[xexyl]

.. shouldn't the reference to winner in rules and guidelines remain the same for historical purposes? Or do you want me to change those too? Well anyway going for the night .. unsure if I'll do anything here tomorrow or not. Good night!

Can see it both ways: perhaps you are correct and that the historic rules and guidelines should be let alone?

I see it both ways too. But something to consider: often enough authors have referred to the guidelines and rules. One entry writes out part of the guidelines too. Not at laptop right now to check but if it wrote part that uses those terms it would be no longer valid. That itself is reason enough to not do it.

Good points. Let us not change terms in these historic documents.

Sounds good. Indeed that entry does refer to the word 'entry' though in that case it is valid and I don't think it would in the document be changed. Still maybe other things that would would make it different so that entry itself is reason enough to not change it even besides the other reasons.

HOWEVER .. it probably should be done in the top level README ? Maybe in that file though there should be a historical note about it. Since it's a significant part of the contest history perhaps you would like to do this part if you agree with me there?

Yes, to both.

Thanks. I'll look out for the changes and mention anything I see that might be worth changing. But since you have the history of introducing typos deliberately (due to the original accident) that might not be good to do anyway (hence why I'd bring them up rather than just change them).

I can look at the other places though. However right now not even at laptop and won't be for a bit. I am feeling pretty good right now: managed to sleep in which is super useful for today: naturally! I hope that I will be at laptop in an hour or 1.5 hours. Hope you're sleeping well my good friend!

Best wishes for a Happy and Fun birthday 🎉🎂🥳

THANK YOU! It was fabulous! Thank you for contributing to it!

[xexyl]

Regarding comment 19418166070:

Please do:

git grep winner

Will do.

and let me know what else you think might need to change.

OK.

Also was I supposed to check another word or more than one word?

We do not understand that last sentence.

I meant are there other words I should have changed?

We managed to sneak in commit 86b8c91 and commit b805203 during a lunch break (that might not happen again for a few days).

No worries there. I won't be doing much for a few days either as you know.

We changed winners to entries in inc/sidenav.default.html and then did a make www (after reordering to put the _form_entrytarball rule after _entryindex) as a quick way to eliminate a number of the cases where winners was found in web pages.

Thanks.

As git grep -l winners shows, and ignoring these cases:

• tmp/OLD_manifest/*
• winners.html
• archive/historic/*
• 1984/anonymous/README.md
• 1984/anonymous/index.html
• README.md
• tmp/*

We see that:

git grep winners 2>&1 | egrep -v 'tmp/|archive/historic|1984/anonymous'

shows a number of cases (probably most?) where winner[s] could and probably should be changed. Please review and change as you think best.

I'll look at this in the next few days I guess.

One thing we cannot change right now is the winner repo name. Doing that would not be wise at this time, if ever. So references to the winner repo name should remain. And it is probably not that bad as the term winner refers to both authors and entries. So yea, the winner repo name should probably not change.

Agreed. I don't think it should be changed at all either (at least at this point? .. but probably ever).

Replying to this comment (reply to your reply to my reply ....) so I am more likely to see it in the next days. But I'm done here for the day. Thanks again for the numerous birthday wishes and helping in making it great!

I hope to do some commits tomorrow but we'll see. Good day!

[xexyl]

Regarding comment 19418166070:

Please do:

git grep winner

Will do.

and let me know what else you think might need to change.

OK.

Also was I supposed to check another word or more than one word?

We do not understand that last sentence.

I meant are there other words I should have changed?

We managed to sneak in commit 86b8c91 and commit b805203 during a lunch break (that might not happen again for a few days).

No worries there. I won't be doing much for a few days either as you know.

We changed winners to entries in inc/sidenav.default.html and then did a make www (after reordering to put the _form_entrytarball rule after _entryindex) as a quick way to eliminate a number of the cases where winners was found in web pages.

Thanks.

As git grep -l winners shows, and ignoring these cases:

• tmp/OLD_manifest/*
• winners.html
• archive/historic/*
• 1984/anonymous/README.md
• 1984/anonymous/index.html
• README.md
• tmp/*

We see that:

git grep winners 2>&1 | egrep -v 'tmp/|archive/historic|1984/anonymous'

shows a number of cases (probably most?) where winner[s] could and probably should be changed. Please review and change as you think best.

I'll look at this in the next few days I guess.

One thing we cannot change right now is the winner repo name. Doing that would not be wise at this time, if ever. So references to the winner repo name should remain. And it is probably not that bad as the term winner refers to both authors and entries. So yea, the winner repo name should probably not change.

Agreed. I don't think it should be changed at all either (at least at this point? .. but probably ever).

Replying to this comment (reply to your reply to my reply ....) so I am more likely to see it in the next days. But I'm done here for the day. Thanks again for the numerous birthday wishes and helping in making it great!

I hope to do some commits tomorrow but we'll see. Good day!

Hmm .. I've kind of forgotten as it's been hectic (not all bad but busy and hectic days too). I should change the 'winners' to 'entries'? Or 'winning entries'? As I noted before I think the latter is more clear but I know you have cases where it has to be a single word too. Maybe I can look at it tomorrow if you get back to me here. Off to do other things.

[lcn2]

Hmm .. I've kind of forgotten as it's been hectic (not all bad but busy and hectic days too). I should change the 'winners' to 'entries'? Or 'winning entries'?

Probably depends on context. In some cases "winning entries" helps, or even "IOCCC winning entries". In other cases just entries if obvious, especially if "winning entries" was mentioned previously.

UPDATE 0

This is why parts of this task cannot be done with a tool such as sgit(1). A human such as yourself, needs to use some level of judgement.

Saying "winning entries" every time will be boring and repetitive.

When looking at, say, a README.md text of an IOCCC entry that won, one does not need to state "winning entry" because the context is obvious, for example.

Use your judgment.

[lcn2]

With commit a1633df222d9b7997d40d9ecff6cebabbbefa3e4, the TODO "Update source for for all IOCCC tools to refer to the IOCCC terms" is now complete.

[lcn2]

With commit ddb6c288b59a63c4f48177e41ab00328e14346d2, the TODO "Update all IOCCC documentation to refer to the IOCCC terms" is now complete.

[lcn2]

With commit 120869a4b2a394b17335157569145809b3da1b7f, the TODO "Create a FAQ entry for each IOCCC term" is now complete.

[lcn2]

As this stage, only the following TODO is left to be done:

• Modify, if needed, all entry and year level README.md files if needed, to use IOCCC terms consistently in both the short and longer forms

There may not be much to modify, assuming that a number of historic uses of "out of date and/or ambiguous" terms might need to be left alone for historic purposes. And if there authors that use "out of date and/or ambiguous" terms in their part of their entry's README.md text, their text might need to be left alone for similar historic reasons.

We use might in the "might need to be left alone" phrase above, because there may be cases where changing to use the current terms "Author, Entry, and Submission" might improve things. Some judgement needs to be applied in these cases.

There are, no doubt, some instances where the above 3 commits that claim "is now complete" missed something. Such a miss, if is important and/or useful to fix, can always be addressed in some future pull request.