Ideas of new section

[tkoyama010]

Thank you for repository! I love thins kind of discussion. I have some section ideas in this repository.

1. "LICENSE" section. Clear common LICENSE feel safe for people.
2. "Using Gif animation" section. Gif animation have a huge impact for people.
3. "requirement" section. People want to know if they can use this in their environment(OS, library, vecsion etc.).
4. "Author" section. People want to know who make this.
5. "VS." section. This is not common. But it is import to compare project with other similar one. People want to know what is the best point of this project. (Be careful not to misunderstand and slander other tools.)
6. "Translation". This is also not common. But some project have a README in multiple languages. It is not possible for developers themselves to prepare multilingual READMEs, but it makes sense to ask for help in translation.

[banesullivan]

Thank you for the feedback, @tkoyama010!! Many of these are excellent sections to include in a README! And I have some opinionated responses to a few of these:

1. It's my opinion that this does not need to be in the README as the LICENSE file has become ubiquitously expected to exist for any open source project and is supposed to ship along side the README to package managers (though it doesn't always. I'll admit). Further, GitHub does a great job of detecting the license and putting it on the main page of the repository. I think its perfectly fine to include this in a README, but it's my opinion that it is unnecessary. I'll see if I can put a note about this somewhere
2. GIF animations while IMO are extremely helpful can also be "loud"/distracting and I know many people that do not like them. I think it makes sense to use GIFs for many examples, so I may add little blurb about this next to screenshots in the Usage section.
3. Ah yes! Good point - the installation guide should have what is minimally required to run the software. I find it acceptable to assume users are using the reasonably up to date and just say pip install xyz for most python packages but it is best to clarify supported versions/etc. in case you stop maintaining the software.
4. This is an excellent point which I thought I mentioned but didn't. One of the core questions someone should be able to answer is "who made this and can I trust them?" I will put some thought into how I can include that here.
5. This is incredibly useful but something I may personally save for the documentation. Otherwise, I'd put this in the general Overview section as a quick/honorable mention.
6. Another great but uncommon thing! I'll see how I might be able to include a note about this.

[banesullivan]

All of these are excellent things to include in a README and what I'm trying to here is balance what is most important to "sell the software" with all of the best practices and relevant information. Further, I'm trying to develop a template of sorts for myself and colleagues who often have trouble writing a README at all -- I want to keep the barrier to writing an informative README as low as possible so that people actually do write them

[banesullivan]

I incorporated many of these points in #3. Thank you, @tkoyama010!