-
Notifications
You must be signed in to change notification settings - Fork 154
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
Update project infrastructure documentation #879
base: main
Are you sure you want to change the base?
Conversation
This commit removes references to the Directory generator, which has been deprecated. The LF now has a centrally maintained tool that does this for us. There are also a few other changes to the project tooling guidance that have occurred over the past few years, and the documentation had gotten a little stale. This commit includes updates where appropriate. Signed-off-by: Brian Warner <[email protected]>
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. Thanks!
FYI: Even though the changes to our GOVERNANCE in this PR are minimal, I believe this language from our GOVERNANCE still applies:
|
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
@@ -154,7 +154,7 @@ Once a PR is ready to be landed, the CPC member who lands the pull request shoul | |||
* Send a notification to the project contacts for the project identified in the PR | |||
indicating that a new Regular CPC member has joined the CPC on behalf of the project. | |||
* Add the member to the github `cpc-regular-members` [team][cpc regular members team] | |||
* Add the member to the `cpc-private` email list and private directory by opening a PR against the [OpenJS Foundation CPC directory][] | |||
* Ask the LF to add the member to the `cpc-private` email list |
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.
This needs to be made a little more explicit. Especially "the LF" needs to be at the very least expanded. Ideally an email address or link to a ticketing system should be provided.
@@ -3,12 +3,15 @@ | |||
The OpenJS Foundation provides a number of services to support critical infrastructure for hosted projects. We expect projects to be respectful of these services, to abide by their terms of use, and to be put into use for the good of the project and the OpenJS Foundation. | |||
|
|||
## Billing for services and mitigating the bus factor | |||
**For all project services, please add an OpenJS Foundation account at an owner or highest-level of permission access.** This helps ensure continuity by reducing the bus factor on the project, and ensures you are never locked out. It is also **required** in order for the OpenJS Foundation to pay service fees on behalf of your project. Access to the OpenJS Foundation administrator/owner account will never be shared with others, and will only be granted to operations, IT, and finance staff at the Linux Foundation. | |||
**For all project services, please add an OpenJS or Linux Foundation account at an owner or highest-level of permission access.** This helps ensure continuity by reducing the bus factor on the project, and ensures you are never locked out. It is also **required** in order for the OpenJS Foundation to pay service fees on behalf of your project. Access to the OpenJS Foundation administrator/owner account will never be shared with others, and will only be granted to operations, IT, and finance staff at the Linux Foundation. |
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.
Adding a "Linux Foundation" account creates an additional risk for continuity should the OpenJSF decide to rely on a different service provider at some point.
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.
the LF isn’t a service provider, it’s the parent organization as i understand it - it’s not likely to ever change.
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.
So it's somewhere in the middle, OpenJS Foundation is a separately incorporated entity but it is fully managed by the LF through a multi-year management services agreement. Many other things would need to be untangled if that ever were to change, and generally speaking from personal experience, adding the Linux Foundation accounts directly will be more operationally efficient.
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.
Centralization is always more operationally efficient. It also creates vendor lock-in (which negatively impacts an org's ability to negotiate agreements, even if intends to stay with the same vendor).
As always, balancing between the two should be done on a case per case basis (it's basically a cost/benefit ratio analysis).
Here, given that projects had to include the OpenJSF's GitHub account up until now, opening that up to now also include the LF's GitHub account isn't going to create any operational efficiency (unless there's a plan to deprecate the OpenJSF account down the line).
|
||
## Source Control | ||
By default all OpenJS Foundation projects have open source repositories in their own GitHub Organizations. The OpenJS Foundation admin account must be added as administrator for each repository. Two-factor authentication must be required for everyone in the organization. | ||
By default all OpenJS Foundation projects have open source repositories in their own GitHub Organizations. The `thelinuxfoundation` admin account must be added as owner for each organization. Two-factor authentication must be required for everyone in the organization. |
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.
Same concern as above. What's the argument for entangling the OpenJSF's recovery planning with the LF's?
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.
FWIW this is not the case for nodejs
or electron
, and as Electron's voting member my understanding is that we would 100% not be okay with this at present without direct discussion with the Foundation's staff on details.
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.
Lots of welcomed cleanup, here. Thank you!
I do want to gently push back against merging OpenJSF's continuity planning with the LF's. Sure the LF's responsible for operations, but the two organizations are independent, and separating accounts for the two seems like a healthy and cheap best practice.
+1 to @tobie's request. Given how the Foundations are structured and the general spirit of how we've approached setting up structures for the OpenJS Foundation's independence in the past, I'd wildly prefer the separation. |
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.
formalizing my previous comment
@joesepi given this hasn't landed in 4 months, I'd rather we change it and get it fixed in this PR (or a replacement) over merging something two CPC members are -1 on. |
So the request is to delay landing a PR that accurately documents how things exist today, to make changes to how things exist today and then land the PR to reflect those changes? Changes that may take time. And during that time, our documentation should remain out of date? I think these are two different things. I think our documentation should be accurate (land this PR) and we should open a new issue to address the concerns raised in this issue. How long this PR has been open is besides the point in my mind. We were just talking about cleaning up the repo, and this is something that had fallen off the radar. But now that it is back on the radar, I think we should merge it and move the concerns to a new issue. If I am misunderstanding, please correct me. |
Resources and base themes (please contribute other templates as you find them): | ||
* The [Amethyst theme](https://github.com/qunitjs/jekyll-theme-amethyst) is maintained by @krinkle for use with GitHub Pages. |
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.
Extremely -1 on us calling out free things in this document. It devalues the non-free things that the Foundation does provide.
## Security scanning | ||
The Linux Foundation offers scanning through [LFX Security](https://lfx.linuxfoundation.org/tools/security/). There is no cost for this service. | ||
|
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.
AFAIK this is free for anyone, and should not be included here.
@@ -33,10 +36,13 @@ Projects with a technical need for a CDN should attempt to use no-cost services | |||
## Website Monitoring | |||
The OpenJS Foundation can provide website downtime and performance monitoring through StatusCake or Pingdom. | |||
|
|||
## Security scanning | |||
The Linux Foundation offers scanning through [LFX Security](https://lfx.linuxfoundation.org/tools/security/). There is no cost for this service. | |||
|
|||
## Open Source Dependency Monitoring (FOSSA) |
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.
We should probably drop this? Unclear, it's just a heading.
## Open Source Dependency Monitoring (FOSSA) | ||
|
||
## Credential Storage | ||
The OpenJS Foundation can provide credential storage and sharing through LastPass Enterprise. Because the credentials are shared through a LastPass Enterprise account, each user only needs a free account to receive them. Managed credentials may include: | ||
The OpenJS Foundation can provide credential storage and sharing. Because the credentials are shared through a LastPass Enterprise account, each user only needs a free account to receive them. Managed credentials may include: |
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.
Do we still use LastPass Enterprise?
@@ -46,14 +52,14 @@ The OpenJS Foundation can provide credential storage and sharing through LastPas | |||
The OpenJS Foundation uses Groups.io for mailing lists on the openjsf.org domain. All projects are welcome to request their own lists on the @lists.openjsf.org subdomain. | |||
|
|||
## Slack | |||
Projects are welcome to create channels on the OpenJS Foundation Slack (https://openjs-foundation.slack.com), or set up their own free Slack workspace. | |||
Projects are welcome to create channels on the [OpenJS Foundation Slack](https://openjs-foundation.slack.com), or set up their own free Slack workspace. |
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.
Projects are welcome to create channels on the [OpenJS Foundation Slack](https://openjs-foundation.slack.com), or set up their own free Slack workspace. | |
Projects are welcome to create channels on the [OpenJS Foundation Slack](https://openjs-foundation.slack.com). |
|
||
## Zoom | ||
Projects may request that standing meetings be added to the OpenJS Foundation calendar. The OpenJS Foundation currently has two Zoom Pro meeting accounts, and one Zoom Webinar account which is capable of livestreaming. Please be mindful of conflicts with other projects by requesting your meeting be scheduled on the shared calendar via email to [email protected]. | ||
Projects may request that standing meetings be added to the [OpenJS Foundation calendar](https://calendar.openjsf.org). The OpenJS Foundation currently has multiple Zoom accounts capable of livestreaming. Please be mindful of conflicts with other projects by requesting your meeting be scheduled on the shared calendar via email to [email protected]. |
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.
This feels like it should probably be two separate points - calendar being one, streaming being another.
6341ff2
to
6ab78be
Compare
This commit removes references to the Directory generator, which has been deprecated. The LF now
has a centrally maintained tool that does this for us.
There are also a few other changes to the project tooling guidance that have occurred over the past
few years, and the documentation had gotten a little stale. This commit includes updates where
appropriate.
Signed-off-by: Brian Warner [email protected]