RFC: 0107 construct library module lifecycle

[ccfife]

---

title: "RFC: #107 Construct Library Module Lifecycle"

---

Ready for review

Rendered version

---

By submitting this pull request, I confirm that my contribution is made under
the terms of the Apache-2.0 license

[eladb]

This is great! I love it. I think it captures the process well and doesn’t introduce too much additional friction.

We are still thinking what’s the best way to vend experimental code. @rix0rrr is writing the RFC (#116).

[nija-at]

This doc has the right content and captures our thinking of construct library graduation well.

However, a few things need to be ironed/detailed out -

Some items are very specific (how to find stakeholders, when is usage considered sufficient), while others are somewhat generic and not quite clear on their actions (observe for metrics, update tracking issue with primary use cases and required constructs, etc.).

The goal of the doc should be that every construct module owner and the squad should be to set up a mechanical process for graduating libraries (obviously, some of the engineering tasks like design reviews and bug fixes will not be mechanical).

If there are two or more places a piece of information is duplicated (for example, package.json and the roadmap), this doc should make it mechanical and hard to keep these up to date. Ideally, we should automate this and shouldn't need to update multiple places. We've already had a part of this problem where the spreadsheet we had is/was out of date with the metadata in the package.

We should capture a set of items at the bottom on the gaps in launching the advocated process.

[nija-at]

I would suggest we split these off into a separate doc. prioritization ≠ lifecycle.

We need to make construct library prioritization work mechanical and easy. Tenets are not sufficient.

[ccfife]

I'd argue that prioritization is the first step in the lifecycle, no?

[nija-at]

I was also wondering if there's a standard format for writing process documents of this nature.

[nija-at]

LGTM. Take a look at some comments below and my response here - #108 (comment)

[nija-at]

Take another pass and identify opportunities to automate, particularly when some action is performed or threshold is reached; and we don't realize that it has happened.
For example, a new module is created as CFN only because of new CloudFormation artifacts. This happens automatically, so we'll need some way of notifying somewhere to add the activities to be performed around it. Similarly, there may be metrics that we don't currently track that may be part of a checklist, etc.

[ccfife]

OK, I've made a few edits to address this. At this point I think this RFC is serviceable. Let's go through a couple construct module graduation cycles and then refine based on what we learn.

[eladb]

Merge!