Skip to content

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

Merged
merged 13 commits into from
Nov 19, 2022

Conversation

dreamorosi
Copy link
Contributor

Description of your changes

This PR includes:

  • New public Project board
  • New Roadmap page on the docs
  • New MAINTAINERS.md document in the repo
  • Updates to some of the scripts executed as part of the workflows & issue templates
  • Update to MkDocs (housekeeping)

Project 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

  • My changes meet the tenets criteria
  • I have performed a self-review of my own code
  • I have commented my code where necessary, particularly in areas that should be flagged with a TODO, or hard-to-understand areas
  • I have made corresponding changes to the documentation
  • I have made corresponding changes to the examples
  • My changes generate no new warnings
  • The code coverage hasn't decreased
  • I have added tests that prove my change is effective and works
  • New and existing unit tests pass locally and in Github Actions
  • Any dependent changes have been merged and published in downstream module
  • The PR title follows the conventional commit semantics

Breaking change checklist

  • I have documented the migration process
  • I have added, implemented necessary warnings (if it can live side by side)

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.

@dreamorosi dreamorosi self-assigned this Nov 15, 2022
@pull-request-size pull-request-size bot added the size/XL PRs between 500-999 LOC, often PRs that grown with feedback label Nov 15, 2022
@dreamorosi dreamorosi added documentation Improvements or additions to documentation and removed documentation labels Nov 15, 2022
ijemmy
ijemmy previously approved these changes Nov 15, 2022
Copy link
Contributor

@ijemmy ijemmy left a 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.)

Comment on lines +80 to +97
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`);
Copy link
Contributor

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)

Copy link
Contributor Author

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?


[![Join our Discord](https://dcbadge.vercel.app/api/server/B8zZKbbyET)](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/).
Copy link
Contributor

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
Copy link
Contributor

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"

Copy link
Contributor Author

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.

@dreamorosi dreamorosi merged commit 36caa4e into main Nov 19, 2022
@dreamorosi dreamorosi deleted the docs/add_maintainers_and_public_roadmap branch November 19, 2022 12:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
documentation Improvements or additions to documentation size/XL PRs between 500-999 LOC, often PRs that grown with feedback
Projects
None yet
2 participants