-
Notifications
You must be signed in to change notification settings - Fork 153
docs: add maintainers and public roadmap #1167
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
Conversation
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 PR is a bit too big. Could we have smaller version next time? (e.g. one for issue template change, one for doc change, etc.)
const labels = issue.labels | ||
.filter((label) => label.name != LABEL_PENDING_RELEASE) | ||
.map((label) => label.name); | ||
|
||
try { | ||
await gh_client.rest.issues.update({ | ||
repo: repository, | ||
owner: owner, | ||
issue_number: issue.number, | ||
state: "closed", | ||
labels: [...labels, LABEL_RELEASED], | ||
}); | ||
} catch (error) { | ||
console.error(error); | ||
throw new Error("Failed to close issue") | ||
} | ||
|
||
console.info(`Issue number ${issue.number} closed and updated`); |
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.
(non-blocking)
While I love the automation, I'm a bit concerned if we could close the issue unexpectedly?
(e.g. an issue with multiple PR and a lot of on going work like a feature request)
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 can reopen those issues if needed.
The idea is that if there's a "big feature issue" like Idempotency, we should have smaller issues for each one of the work streams, and each PR should correspond to one of these issues, not the main bigger one.
What do you think about trying this out and , if it doesn't work or becomes a hassle, remove it in a few weeks?
|
||
[](https://discord.gg/B8zZKbbyET) | ||
|
||
A suite of utilities for AWS Lambda functions to ease the adoption of best practices such as tracing, structured logging, custom metrics, and more. | ||
|
||
You can use the library in both TypeScript and JavaScript code bases. | ||
|
||
AWS Lambda Powertools for [Python](https://github.com/awslabs/aws-lambda-powertools-python) and AWS Lambda Powertools for [Java](https://github.com/awslabs/aws-lambda-powertools-java) are also available. | ||
> Also available in [Python](https://github.com/awslabs/aws-lambda-powertools-python), [Java](https://github.com/awslabs/aws-lambda-powertools-java), and [.NET](https://awslabs.github.io/aws-lambda-powertools-dotnet/). |
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 need to tag Stephen when this PR is merged :)
|
||
[See our latest list of activities »](https://github.com/orgs/awslabs/projects/76/views/2){target="_blank"} | ||
|
||
## Themes |
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.
(non-blocking)
Is Themes the right term here?
Some ideas: "Upcoming release", "High-priority features"
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 all of them are features: i.e. improving end-to-end tests could be an area we might be working on, but it doesn't result in a feature.
And I'm a bit reticent with using "upcoming release" as it could generate the wrong expectations. This is somewhat related to the point above, but also to the fact that we don't want to commit to a specific timeline, at least for now. For instance, between now and when we finally release Idempotency, there might be many intermediate releases.
Description of your changes
This PR includes:
Roadmap
page on the docsMAINTAINERS.md
document in the repoProject board
Technically this is not part of the PR (you won't find it in the diff), however the work done on this is very much related so I'm including it here for context.
I got the idea for this board from @heitorlessa and saw how he (mainly) and the rest of the maintainers use it. This board is meant to replace the two other boards (now closed) that we had for issues and PRs that kind of fell out of usage.
I don't expect other maintainers to use it, but you're welcome to if you'd like. I intend to use it as single pane of glass to monitor the repo and use it to drive discussions during our team meetings.
The repo will contain only issues, labeled and grouped by stage. PRs won't be directly added to the board but will be linked to issues (each PR already requires an issue).
I would appreciate if all maintainers could familiarise themselves with the new labels, feel free to ask questions if something is not clear. The labelling strategy largely comes from the proposal made by @balabad in #306 a long while ago.
Roadmap page
This page is similar to the one found in the main Powertools' repo.
I have added this page to have something to refer to/link whenever discussing with customers our current priorities. You'll notice that there are no dates/deadlines (this is on purpose) and that for now it includes the current priorities we have discussed some time ago.
It also details the process we have used/we'll be using to treat roadmap items.
Maintainers page
This document is also similar to the one found in the Powertools for Python repo.
The purpose of this document is to be akin to a maintainers handbook. I initially decided to add it mainly to document the new labels, but then I also thought that having this type of document will help community members to better understand how we operate the repo and inform potential future maintainers about what the role is about.
In the future I'd like to move over some of the explanations about testing from the "Contribute" document as well as adding details about our CI/CD process (#1038) and release process.
Updates to scripts & issue templates
Some of the scripts run as part of workflows around PRs automatically add new labels to PRs. The changes update these labels to match the ones discussed above.
Similar to the scripts, the issue templates automatically assign some labels to new issues. The changes update these default labels.
Updates to MkDocs
This is mainly an housekeeping change. While checking the config in the Python's repo I noticed that we had an older version and so I snuck in the change.
How to verify this change
The main project board can be found at this link: AWS Lambda Powertools for TypeScript
The rest of the changes can be reviewed in the diff.
Related issues, RFCs
Issue number: #306
PR status
Is this ready for review?: NO
Is it a breaking change?: NO
Checklist
Breaking change checklist
By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.