Pain points summary from an external contributor.

_While most Issues are about quadrant 1, this one's about quadrant 2._


# Overview
As a contributor to amplify-cli, I've noted a few pain points that both create friction for new developers to begin working on real bug fixes in the framework, and slow down the velocity of experienced external developers who are looking to make a positive impact on the project. I believe while these are not-urgent tasks, they are very important and directly relate to the health and ultimately success of the project.

## Pain Points

### Contributing is harder than it needs to be.
1. There are too many Github Issues for anyone to effectively manage. It's hard to know what is a priority.
2. The project roadmap is not visible to outside contributors. It's hard to know if my ideas on the future state of the framework align with the core teams.

### My PRs take a long time to merge- is the current CI strategy working?
3. The git hook on commit is a terrifically frustrating user experience. I'm certain there must be a better way to solve whatever problem this is trying to solve.
4. There are a lot of CI integrations that (while in some cases adding value) distract from the more important metrics of what makes a contribution valuable.

### It's hard to comprehend the code base.
5. Intellisense does not work on some of the most crucial aspects of the code like `context.amplify.helperUtils()`. Dynamic imports and other dependencies techniques make it extremely hard to trace which functions are being called, what they do, and where they are defined.
6. Types are inconsistently applied in the code. Would probably have been better off as just javascript for conciseness and a lower barrier to developer comprehensibility.

### The project architecture is confusing.
7. The code base is structured as a monorepo with lots of sub-modules, but there is no documentation on how to independently build and test packages outside of the monolithic CLI tools. It's unclear if its that's possible with cross dependencies. Theoretically, if they could be installed and run standalone, it would make it _a lot_ easier to black box them in isolation and verify they are fully independent modules. What if FE devs could use a `amplify env` "lite" CLI for a shared-backend workflow?
8. It's unclear how a new plugin transitions to become a core part of the CLI tools. I see similarities in the code structure, but no documentation on this.
9. There is a lot of added complexity in the framework to support multiple providers, but the only provider that is supported and will receive support is (AFAIK) awscloudformation. Feels like a big case of YAGNI here.

### There's a disconnect between user pain points and what contributors work on.
10. Many believe bugs fixes should be prioritized higher than new features, if there is a reason this isn't the case, communicating it would alleviate their concerns.
11. Refactoring seems to only be prioritized when coupled with adding support for new features. This is a problem faced by every software project, but it's one that will get harder to fix as time goes on.

**Amplify CLI Version**
latest

**To Reproduce**
Be an active open source contributor.

**Expected behavior**
It shouldn't be this hard to contribute.

**Additional context**
Odds are good I'm somewhere in the first half of this chart when it comes to working under-the-hood on the Amplify CLI code base.
I'm making this post now before I enter into the middle of it and resign myself to the problems and friction I felt early on.

If I wait until I'm in the second half, I'd almost certainly have forgotten all the pain points for a new contributor, and lost touch to the point where I wouldn't be able to relate to them or consider alternatives.

My points may not _all_ make sense to someone who's been working on the framework for a long time. I know they do resonate with many who like me are trying to improve the framework, and feel there is more resistance than there should be.

If you believe this has value, please share/tag others. Otherwise, feel free to close.