chore: add missing titles (#290)

docs/drafts/DEPRECATE-GUIDELINES.md

@@ -1,20 +1,22 @@
-# What?
+# Package deprecation
 
-This is guidelines for unmaintained packages.
+## What?
 
-# Why?
+These are guidelines for unmaintained packages.
+
+## Why?
 
 To ensure that packages in the Node.js ecosystem are up to date or gracefully deprecated.
 
-# How?
+## How?
 
 These guidelines exist to help with a course of action for package consumers and owners to take in the event that a package becomes unmaintained.
 
 - Provide a baseline and common practices for identifying unmaintained packages
 - Give package consumers some help with unmaintained packages.
 - Give package owners some help with handling and deprecating packages.
 
-## What consititutes an unmaintained package?
+### What consititutes an unmaintained package?
 
 It's not always obvious if a package is unmaintained. Many packages are small and considered completed as published. A long period of no activity does not imply that a project is not maintained.
 
@@ -29,7 +31,7 @@ Some criteria to determine if it's unmaintained:
   - Known vulnerabilities identified by `npm audit` or other parties
   - Package is known to fail for LTS Node.js
 
-## For Users
+### For Users
 
 If you are using a package that meets your requirements but you found issues or need enhancements, then these are some actions you can follow:
 
@@ -39,7 +41,7 @@ If you are using a package that meets your requirements but you found issues or
   - Check if its `package.json` has a `support` field that indicates its support status.
   - Open the "repository" link if it has one to view development activities (you can run `npm repo $package` to do this as well)
 
-### Identifying unmaintained package?
+#### Identifying unmaintained package?
 
 When you've opened the package's repo, to further check development activities:
 
@@ -60,7 +62,7 @@ When you've opened the package's repo, to further check development activities:
 
 - Check last activity on github issues and PRs. If there're no responses within some reasonable time to high priority issues or PRs, then consider the package as an unmaintained candidate.
 
-### Taking Further Actions
+#### Taking Further Actions
 
 Once you've identified a package may be unmaintained, there are some basic actions you can take to help yourself:
 
@@ -72,7 +74,7 @@ Once you've identified a package may be unmaintained, there are some basic actio
 - Search for a maintained alternative that may meet your requirements better.
 - Please open an issue for the Node.js package-maintenance working group so that we may request for npm ownership in case someone's interested in maintaining the package.
 
-## For Package Owners
+### For Package Owners
 
 If you own a package and you want to stop maintaining it, then please help your users by making it known. Some simple actions you can take:
 
@@ -81,7 +83,7 @@ If you own a package and you want to stop maintaining it, then please help your
 - Reach out to the Node.js package-maintenance working group to offer us ownership so we can hand it off to a new owner.
 - Update the `support` levels in your `package.json` according to the [support level doc]
 
-### `npm deprecate` command
+#### `npm deprecate` command
 
 - npm has the "deprecate" command, you can utilize this.
 - You can use semvers to deprecate a range. ie: `npm deprecate package@^1.0.0`
@@ -91,20 +93,20 @@ If you own a package and you want to stop maintaining it, then please help your
     - ie: `npm deprecate package@1.0.0 ""`
 - Please consider marking an old version with crtical issues or vulnerabilities as deprecated.
 
-### Mark abandoned/unmaintained
+#### Mark abandoned/unmaintained
 
 - Use a special `npm deprecate` message such as `"abandoned and unmaintained"` to mark a package as abandoned.
 
   - no need to publish a new package to mark it abandoned.
   - but only owners can `npm deprecate` a package.
   - please consider giving the package-maintenance working group ownership to the package on npm.
 
-### Identify replacement
+#### Identify replacement
 
 - If a package is fully unmaintained, then a replacement should be identified and added to the deprecation message.
 - If no replacement exists, then please identify the safe versions to use in the deprecation message.
 
-## Further Ideas and Tools
+### Further Ideas and Tools
 
 There are some ongoing discussion related to npm to make managing unmaintained packages easier.
 

docs/drafts/PUBLISH-GUIDELINES.md

@@ -1,19 +1,21 @@
-# What?
+# Publishing packages
 
-This is guidelines for publishing packages to the npm registry.
+## What?
 
-# Why?
+These are guidelines for publishing packages to the npm registry.
+
+## Why?
 
 After you publish your package to the public npm registry, it's visible to everyone on the internet and your users will install your package into their `node_modules`.  There are a few reasons that keeping your published package tidy:
 
 - Security - avoid accidentally publishing your credential files like keys
 - Tidiness - avoid publishing non essential temp files like `.nyc_output` or `coverage`
 
-# How?
+## How?
 
 These guidelines exist to help package owners with some practices on managing packages for publishing.  The primary focus is about filtering files that are published, but there are other helpful related resources as well.
 
-## Overview
+### Overview
 
 [npm] maintains a public registry for everyone to publish packages.  Here are some related resources:
 
@@ -26,7 +28,7 @@ These guidelines exist to help package owners with some practices on managing pa
 | search/view published packages | [public registry]           | [for example](https://www.npmjs.com/package/npm)          |
 | filter publish files           | [`.npmignore`] or [`files`] | Use one base on your preference                           |
 
-## `.npmignore` or `files`
+### `.npmignore` or `files`
 
 [npm] has default ignore rules and loads from `.gitignore` but it also offer two methods for you to keep your published packages tidy.
 
@@ -51,7 +53,7 @@ On the `files` field in `package.json`:
   - The result is npm's default ignore rules has no effect on files under directories that are whitelisted by `files`.
   - For example, if you set `"files": [ "lib" ]`, then `lib/.gitignore` will be published and there's no easy way to avoid that.
 
-## Verifications
+### Verifications
 
 Run `npm publish --dry-run` to check what you are about to publish first.  In the newer [npm] version 6, [`npm publish`] now shows the list of files so you can inspect that also.
 
@@ -61,25 +63,25 @@ You can also use the [`npm pack`] command to download a tarball from a published
 
 For example: `npm pack npm@6.5.0`.
 
-## Transpiling Sources
+### Transpiling Sources
 
 A package written in another language like TypeScript should be published with transpiled JavaScript as the primary executable.
 
 Generally the original sources should not be required to use your published package, but it's your preference whether to publish them or not.
 
-## Publish and Install scripts
+### Publish and Install scripts
 
 If your package requires any build steps such as transpiling sources, then note that [npm's recommendation](https://docs.npmjs.com/misc/scripts#best-practices) is to run those before you publish, not when your user install your package.
 
 The [npm scripts] `prepare` and `prepublishOnly` are intended for this purpose.
 
-## Tests and Docs
+### Tests and Docs
 
 For your tests and extra docs, it's your preference on whether to publish them or not.
 
 Keep in mind that tests generally are more relaxed at what they are allowed to do and easier to overlook, so they are a location where someone could potentially hide malicious code to cause harm.
 
-## Other Resources
+### Other Resources
 
 There are tools that help you with the verication and publishing process:
 

docs/drafts/ci-cd-guidelines.md

@@ -1,3 +1,5 @@
+# Continuous Integration / Continuous Delivery (CI/CD)
+
 ## What
 
 Guidelines for CI/CD automation templates to be shipped by the package-maintenance team.