docs: Connector dev standards (#52)

Closes #49

- cleanup the README and add a link out to the connector dev standards
guide
- add connector dev standards guide

Let me know if I missed any tips or if you think theres better
formatting or location for this.

---------

Co-authored-by: Edgar R. M. <[email protected]>

README.md

@@ -11,7 +11,7 @@ Based on the [Maintenance Statuses](#Maintenance-Statuses) we expect that most o
 
 With MeltanoLabs we hope to foster a community of contributors who are well versed in Singer and the Meltano SDK.
 The three roles that exist in MeltanoLabs are maintainers, contributors, and community members.
-Each one has different expectations and level of access to the respositories within MeltanoLabs.
+Each one has different expectations and level of access to the repositories within MeltanoLabs.
 
 ### Community Members
 
@@ -21,12 +21,12 @@ The more community members we have that are using these connectors the faster we
 
 ### Contributors
 
-MeltanoLabs contributors are community members who volunteer to actively make contributions and review pull requests/issues within MeltanoLabs repositories but dont have an explicit maintainer status on any one repository.
+MeltanoLabs contributors are community members who volunteer to actively make contributions and review pull requests/issues within MeltanoLabs repositories but don't have an explicit maintainer status on any one repository.
 This group of community members will be part of the `labs` slack channel and will be the first to hear about repositories that need new maintainer volunteers and general maintenance requests.
 
 ### Maintainers
 
-Connector maintainers are community members who have stepped up to take temporary ownership of a repository's maintainenance.
+Connector maintainers are community members who have stepped up to take temporary ownership of a repository's maintenance.
 Community members can volunteer to be owners of a connector for a specific duration of time.
 This is much more light weight and very different from asking for full-time permanent fork owners.
 The developer can support for the project scope or time duration that makes sense.
@@ -45,7 +45,9 @@ The two main ways that connectors are added to MeltanoLabs right now are either
 MeltanoLabs is a great place for community members to incubate connectors for new sources or destinations in a shared space to make it easier for the community to contribute and maintain it into the future after it leaves the development phase.
 We also encourage community members to use this as a place where existing connectors can be rebuilt or ported over to the Meltano SDK.
 
-If you'd like to create a new connector in MeltanoLabs create an issue labeled "Add New Connector - [your connector name]" in the [Meta repo](https://github.com/MeltanoLabs/Meta) and assign it to @tayloramurphy and @pnadolny13 when youre code is ready to be pushed up to GitHub and they will create you a repository and give you access.
+See the [Connector Development Standards](connector-dev.md) guide for best practices and conventions.
+
+If you'd like to create a new connector in MeltanoLabs, create an issue labeled "Add New Connector - [your connector name]" in the [Meta repo](https://github.com/MeltanoLabs/Meta) and assign it to @tayloramurphy and @pnadolny13 when you're code is ready to be pushed up to GitHub and they will create you a repository and give you access.
 Alternatively you could build it in your own namespace and later migrate it once its ready.
 
 ### Migrating An Existing Connector
@@ -64,11 +66,11 @@ Alternatively you could build it in your own namespace and later migrate it once
 Each repository has a GitHub team with the same name e.g. tap-x where community members can be added.
 The GitHub team is a child of the generic Singer Taps/Targets team.
 The team is then assigned to the repository with "maintain" permissions.
-If a maintainer chooses to pass their maintenance resposibilies to another person, they are simply removed from the GitHub team to revoke privileges.
+If a maintainer chooses to pass their maintenance responsibilities to another person, they are simply removed from the GitHub team to revoke privileges.
 
 ### Finding Maintainers
 
-The initial approach will be to ask for volunteers within the MeltanoLabs community to take ownership of a respository as maintainer but we know that for some less frequently used connectors there might not be enough volunteers.
+The initial approach will be to ask for volunteers within the MeltanoLabs community to take ownership of a repository as maintainer but we know that for some less frequently used connectors there might not be enough volunteers.
 
 In this case we will do the following:
 1. Whenever we receive a PR or Issue for a connector that has no maintainers, we announce this to the contributor.
@@ -84,7 +86,7 @@ If you're a maintainer and no longer have the capacity or desire to be the maint
 - Open an issue in this repository "Relinquish Maintainership - tap-x" and assign it to @tayloramurphy, @pnadolny13, and @afolson.
 - Tag anyone who you suggest to be the next maintainer to get confirmation. It's fine if you don't have someone in mind, we will help find someone from the community.
 - Create a PR to edit the [connector owner table](https://github.com/MeltanoLabs/Meta#connector-owners) in this README to remove your name and optionally add the new maintainer if one exists.
-- A member of the Meltano team will remove you from the connecotr's GitHub team and add the new maintainer.
+- A member of the Meltano team will remove you from the connector's GitHub team and add the new maintainer.
 
 ### Publishing to PyPI
 
@@ -101,19 +103,20 @@ After a short review, the team will enable the PyPI publishing workflow for your
 Active (Stable): The connector repository is well maintained and recommended for use in production environments.
 The repository has all of the following attributes; all known issues and bugs are addressed promptly, changes are expected to go through pull request reviews, releases to main are created on the appropriate cadence, security patches are addressed promptly, a CI pipeline that runs automated testing is present, community contributed pull requests are reviewed in a timely manner, README is complete with examples and detail, etc.
 
-Prerelease (Beta): The repository was recently created and initial development is complete but hasnt been hardened enough for production environments yet.
+Prerelease (Beta): The repository was recently created and initial development is complete but hasn't been hardened enough for production environments yet.
 We encourage the community to start testing out the connector and submit issues or merge requests to help get it to the Active (Stable) status.
 The repository has some or all of the following attributes; most of the features are functioning but edge cases and bugs are still being addressed, changes are expected to go through pull requests and issues, some automated tests but code coverage could be low, optional CI, the README is clear and minimally complete but might be lacking in extensive detail or examples, etc.
 
 Development (Under Construction): The repository is undergoing initial development and is not ready to be used yet.
 Not recommended for use outside of development environments.
-The repository has some or all of the following attributes; the developer might be regularly commiting directly to the main branch, pull requests reviews are optional, no CI/CD, tests might not be passing, README might be sparse, etc.
+The repository has some or all of the following attributes; the developer might be regularly committing directly to the main branch, pull requests reviews are optional, no CI/CD, tests might not be passing, README might be sparse, etc.
 
 Inactive or Stale: The repository has some or all of the following attributes; unresponsive maintainers, many unaddressed issues or pull requests, security patches are not kept up to date, unresolved failing CI pipelines, etc.
 
 Unknown: The status of the connector is currently undefined.
-We encourage community memebers to submit merge requests to update incorrect statuses.
+We encourage community members to submit merge requests to update incorrect statuses.
 
+See the [Connector Development Standards](connector-dev.md) guide for best practices and conventions.
 
 ## Connector Owners
 

connector-dev.md

@@ -0,0 +1,70 @@
+# Connector Development Standards
+
+MeltanoLabs is primarily a place for well-written SDK based connectors.
+As part of that, there's an expected level of quality that each connector should strive to meet.
+Many times the connectors in MeltanoLabs are built from scratch as a brand new connector or rebuilt to replace a legacy one.
+With that in mind this is a compiled list of the development best practices and standards for adding a connector to MeltanoLabs.
+This can also act as a guide for others outside the MeltanoLabs organization to understand the best approach to building a high quality connector.
+
+## Tips For Building From Scratch
+
+### Start With the cookiecutter Templates
+
+When building from scratch always use the cookiecutter to make sure the newest features and recommended scaffold is present.
+This is compared to starting with a clone of an existing SDK repo and modifying it for the new source, which could miss out on some improvements.
+
+### Use the Latest SDK Version
+
+Similarly you should always start development of a new connector using the latest SDK version.
+The SDK has had major improvements over time so making sure you're taking advantage of the latest features and not accidentally reinventing the wheel is important.
+
+### Naming Convention
+
+Generally when deciding the name for a connector we use the `tap-<source>` naming convention.
+- Start with `tap-` or `target-`
+- Use dashes over underscores
+- Avoid extras like `tap-<source>-sdk`, `meltano-tap-<source>`, `tap-<source>-new`, `target-<destination>-loader`, etc.
+- If rebuilding an existing connector it's usually best to keep the same naming convention as existing legacy connectors for clarity within the community.
+For example, prefer `tap-facebook` to `tap-meta` (Facebook's new name) because there's a long history of taps named `tap-facebook` and will be more clear.
+With that consideration in mind, use your best judgement.
+
+## Coding Standards
+
+### Implement Integration Tests
+The cookiecutter comes with default tests and the SDK has a [testing framework](https://sdk.meltano.com/en/latest/testing.html).
+You should implement at least the minimum tests.
+
+### Catalog Support
+
+If your tap uses dynamic schema generation then you should ensure that catalog selection is supported properly.
+Meltano relies on the tap to use the input catalog properly in order to support selection criteria, metadata overrides, etc.
+Ensure that catalog stream, property, and metadata is respected by the tap.
+
+### Dependency Management
+
+- Verify that there are no extra unused dependencies in the pyproject.toml
+- Dependencies for testing should go in the `dev` poetry group
+- pyproject.toml package version and github/pypi release version should match
+- Check for unused imports
+
+### Other Development Tips
+- General coding practices: https://handbook.meltano.com/engineering/dev-standards/
+- All the TODOs from the cookiecutter should be completed and removed in initial development
+
+## Repository Standards
+
+- Tag git releases so users can more easily pin to a specific version.
+- Enable branch protection on the default `main` branch that require PRs and code reviews in order to merge changes.
+- GitHub actions CI workflow for linting and running integration pytests
+- The repo has a license. Generally permissive licenses like MIT and Apache 2.0 are recommended. 
+- Make sure the issues tab is enabled on repo so community members can report errors or request features
+
+## Documentation
+
+- `tap.py` settings are accurate and well documented. tap.py settings should reflect what should be shown on the hub. All content including: required flag, default flag, description, secret flag, etc. should be accurate in the tap.
+- Auto populate the README using the `--about --format=markdown` output whenever `tap.py` settings change
+- Logging, comments, doc strings, function/class/variable naming, etc. should be reviewed for clarity and accuracy
+- Clearly document in the README the feature support comparison of the new tap vs the default variant on the hub and any nuances to be aware of.
+- All known issues and planned improvements should be documented as issues in the repository
+- Add the connector to Meta `src/connector_owners.py` and refresh the README tables
+- Add to MeltanoHub