Testing changes section of README is out of date

[benjaminapetersen]

The Testing changes section of the README is out of date:

You can test any changes locally by cloning this repository and regenerating all data by running ./rerun_data.sh.

At minimum, this ./rerun_data.sh file is now ./src/rerun_data.sh.

I'm new, attempting to follow the instructions here as requested from the Kubernetes Community Membership document. There may be
other items out of date, I'll either update this issue as I go, or create new issues if unrelated.

[lukaszgryglicki]

To update/add you affiliations you need to follow this.

You can update instructions with changes suggested by creating a PR, I will review and approve/merge then.

[benjaminapetersen]

Will be doing the adding flow shortly. I tried the "run test" flow to see if it would give me any feedback before adding myself and noticed that it is no longer accurate.

[benjaminapetersen]

@lukaszgryglicki I will say the "what am I doing" and "why am I doing it" aspect of the add yourself flow is very cryptic. For example, the phrase "We need historical emails to track historical data" probably makes sense to someone, but as a new person I'm already confused seeing the list of dev1, dev2, dev3, dev4, dev5, etc docs and trying to figure out what they mean and why they are structured the way they are. It is also unclear to me why they are so repetitive, the same names appear across multiple files with similar stanzas.

It's not clear if someone is to add themselves just to the doc with the largest number, or if they are to add themselves to multiple documents. I can also intuit that an email address is of the structure foo!bar.com instead of foo@bar.com but I don't know why the @ is swapped for !.

[lukaszgryglicki]

You are very welcomed to propose changes to README.md - this is the first time I see any issue reported that it is not clear, you can see 100s of PRs created approved and merged created by othe rpeople, so I guess README was OK for them. But again, I'm open to any rephrase you can suggest - I'll review and happy to approve & merge.

[benjaminapetersen]

The confusing thing is that it isn't clear where to make a new entry.
The developer_affiliations*.txt files seem to be alphabetical, but also, take the letter M. There are entries in:

• developer_affiliations1.txt
• developer_affiliations6.txt
  Other letters have multiple series as well. What is the directive for adding a new entry for yourself? Should a new PR simply choose a reasonable slot, or is append to the end of the largest <num>.txt also a reasonable option? I think this should be clarified in the README (and I could make the PR if I knew the intent).

[benjaminapetersen]

I'll cite this comment on PR as another example of the confusion:

#507 (comment)

The image is humorous. 🐶 😄
I imagine the risk here of doing the wrong thing is low, so I'm not aiming to be pedantic. I'd just like to clarify intent.

I also commented on this PR that the dev seemed to have edited files that the README indicates are generated, not for human editing.

[lukaszgryglicki]

I can TAL on Friday the earliest, developers* files are sorted alphabetically and lower/UPPER letters are in separate (case sensitive) - usually there is no issue if somebody makes a typo or just adds entry at the end - as I usually update/regenerate this files after other internals tasks, or after merging a bunch of PRs. This wasn't really an issue for me, no matter what people contribute in PRs - I'm usually merging and then correcting in post-merge instead of asking people to fix their PRs.

[lukaszgryglicki]

I've merged your PR. developers* file is automatically generated (internally as one file sorted alphabetically 0-9, A-Z, a-z) and then automatically split into files smaller than GitHub limit for displaying pretty-formatted files (instead of only showing the download option). Feel free to open a PR for README.md and I will review it and merged.

Thanks for your feedback.