-
Notifications
You must be signed in to change notification settings - Fork 16
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
maintainers.html: Add list of maintainers #141
Conversation
🚀 PR preview deployed to https://RIOT-OS-riot-os-org-preview-141.surge.sh |
Currently only the default list of maintainers is rendered, as the token is not set for this PR (as it introduces the usage of this token). I tested it locally, but should we maybe at first not link maintainers.html in the menu and see if when merged to master the result is the correct one? |
Responsive grid
Update CODEOWNER explanation
Fix name in title
Fix explanation on background
Addressed comments, but we now need a re-ACK. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
if the subcaption is fixed, ready to go from my side. thanks @miri64!
Fix subtitle
Done. |
Masonry layout
Truncate full name if too long, use muted styling for full name
Fix fetching to not stringify "None"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good from my side!
Thanks for the review! |
After trying a lot around to get a script running to add the list of maintainers to the documentation (see RIOT-OS/RIOT#21062 )1, @aabadie and I came to the conclusion that it might be best to have a dedicated service to generate the list and then somehow include the generated list into the documentation. All this generation-by-service-stuff, however, made me think: “We already have something like this: riot-os.org, our website, so why not just integrate the list of maintainers into our website?” So I did with this PR. All it takes was to change the access token for the deployment workflow.
Footnotes
Overall conclusion: reading teams needs a token with special permissions, generating the list as artifacts of a dedicated GitHub actions yields the list, but Murdock [and our doc building service] would again need a special GitHub token to download them. ↩