-
Notifications
You must be signed in to change notification settings - Fork 184
Create third-party-services-documentation-policy.md #1482
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
base: main
Are you sure you want to change the base?
Create third-party-services-documentation-policy.md #1482
Conversation
This is the proposed Third Party Services Documentation Policy discussed in openjs-foundation#1425.
This comment was marked as off-topic.
This comment was marked as off-topic.
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.
LGTM
@@ -0,0 +1,121 @@ | |||
# **OpenJS Third Party Services Documentation Policy** |
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.
Here & below: I don't think there's a need for the **
wrappers; headers are bold anyway.
# **OpenJS Third Party Services Documentation Policy** | |
# OpenJS Third Party Services Documentation Policy |
|
||
## **2. Ensure the service registry is accessible to the OpenJS Foundation** {#ensure-the-service-registry-is-accessible-to-the-openjs-foundation} | ||
|
||
Projects have two options on how to approach storing and granting OpenJS access to their service registry file. Regardless of the approach, the service registry file must be accessible to the OpenJS Executive Director Robin Ginn ([@rginn](https://www.github.com/rginn), [rginn@openjsf.org](mailto:rginn@openjsf.org)) and OpenJS Director of Program Management Ben Sternthal ([@bensternthal](https://www.github.com/bensternthal), [bsternthal@linuxfondation.org](mailto:bsternthal@linuxfondation.org)). |
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.
Not that I foresee any changes here... 😉 But should we include concrete people in such documents? If anyone decides to step down, we may have a lot of docs to update.
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.
Agreed. This has come up in different places. What about we have a list of staff members / functions in the repo and just reference those from here?
This is the proposed Third Party Services Documentation Policy discussed in #1425.