After our discussion of AI usage I thought I might just go ahead and follow my own suggestions.
Stating with Caiwyn, I’ll try to add all of the prop specific defines to the POD. I don’t want to power through Fett’s list until I get some feedback
I still find github to be a bt intimidating. I think I made a new commit in my fork and sent a PR. (Is that how you say it?)
But then I noticed:
I added the new info as part of the same page. Can I edit my old commit easily, or do I need to create a new one? I know all of these things are obvious to a developer, so any hand holding is appreciated!
Fwiw, ProffieConfig’s prop data files may be useful, since they’re parsed out from the headers to be something machine readable.
To be pedantic, most of this is just git.
Yeah
Since you titled your PR modifying the config top page, and moving the edits to their own file isn’t really relevant history (it’s its own approach entirely, semantically), I’d probably just close the PR, make a new branch off of main/the commit prior to your edits (you can move between branches to reference your edits or just copy them, since they’re fairly trivial thus far), and redo them in their own file however you see fit.
I’ll redo them in their own file. In order to add links to the CONFIG_TOP page, do I wait for the new file I’ve created to be approved? My logic is no page, no link…
So the steps are:
Make a .md file for one set of prop specific defines.
Submit as PR. Await approval.
Add link as a commit to the CONFIG_TOP section in the POD. (I will add a brief explainer when I add the first link).
Submit PR.
Repeat when I have time to do the next prop.
You could add a section in CONFIG_TOP’s page talking about the existence of prop specific defines with a list of the props, and as you complete one, hyperlink it (as part of your hypothetical later PRs adding another page).
You can make changes to a PR if Fredrik has suggestions. (Via adding new commits to the branch).
I wouldn’t do a separate PR just to add something to CONFIG_TOP. The changes there should be small and relevant to whatever new file you’re doing, and without anything there there’d be no link to a new page. It’s directly relevant, so it should be part of the same PR (IMO).
Obviously there’s some subjectivity here and not really hard rules, but, that’d be my rough judgement.
Generally speaking, the easiest way to make changes to the pod is to just find a page, and click the edit button at the top right, then make the change directly on github.
Maybe not so helpful for creating new files though…
It’s also totally fine to create separate PRs for small changes. (within reason)
Yeah I started by clicking the edit button right on the page in the POD. The ‘link to separate pages’ idea was what tripped me up. Adding to the existing page was pretty easy.
