docs: Clean up some documenation#1181
docs: Clean up some documenation#1181RobLoach merged 1 commit intolibretro:masterfrom offalynne:patch-4
Conversation
Attribution occurs through project documentation and commit history, not contributor graffiti
|
The comment regarding OS version is unnecessary and irrelevant to the purpose of the project #1140, #1148, #1149, #1150, #1153, #1156, #1158, #1159, #1160, #1161, #1164, #1168, #1166, #1167, #1171, #1172, #1174, #1175, #1176, #1177 should similarly be amended or closed outright for an excess of redundant and/or outright mistaken commentary and minimal content |
I understand your concerns about the comments, and I appreciate your feedback. After giving it some thought, I've taken the initiative to remove all comments from the pull requests, including the file associated with this PR. Additionally, I've removed any remaining comments, ensuring that every file is now completely free of comments and everything is clean and streamlined. This includes the file associated with this PR, so please feel free to close this PR at your convenience.
[Edit: It's an overstatement to claim that the PRs have minimal content. Take another look at them now that they are uncommented.] I want to clarify that I didn't append my name to other files or pull requests. The extensive commenting was part of my efforts to manually alter variables from the generated autoconfig files as I learned how to program a script to automate the process. Additionally, the comments in the autoconfig files were intended to protect them from being downgraded by RetroArch users, a mistake I made myself in the past. To address this, I took measures right away by extensively documenting the principles of the controller drivers in our Joypad Auto Configuration guide to help prevent such issues. So I agree that this repository isn't the right place for these comments any more. Also, creating a dedicated release JSON for the controllers I'm working to maintain would be more appropriate. Regarding my work with controllers, I currently own the following:
I'm also planning to purchase a Microsoft Series S/X Wireless controller by the end of the month. These controllers are widely available and are the official controllers for modern gaming consoles. My goal is to ensure their compatibility with RetroArch. I understand it might not be immediately apparent, but reaching this point has required a significant investment of both time and resources. Since May of last year, I've been focused on mastering the generation, modification, and documentation of these autoconfig files. I've also developed configuration scripts for all RetroArch packages, including Flatpak, AppImage, and GNU/Linux packages. This involved dedicating around two months to these efforts, which included submitting the following:
I hope you can understand and support me as I continue to work on these improvements. |
Text was removed to incorporate comments into the autoconfig files following consensus: libretro/retroarch-joypad-autoconfig#1181 (comment). This user guide is sufficiently documented to serve as a reference instead of including comments within the files.
|
I just added a commit with edit summary: "Text was removed to incorporate comments into the autoconfig files following consensus: #1181 (comment). This user guide is sufficiently documented to serve as a reference instead of including comments within the files." |
|
I think we have different ideas regarding what "improvement" means in the context of these changes |
Are my pull requests satisfactory, or is there anything else you'd like me to address? |
RobLoach
left a comment
There was a problem hiding this comment.
I tend to agree here. Much of this is cruft and not needed...
- Attribution is available through git history, and content is licensed as MIT
- While backwards compatibility is important, in general we usually try to target the latest drivers/versions of platforms
- It's known that there are other binding files, as you can see the other binding files in the same directory
Attribution occurs through project documentation and commit history, not contributor graffiti