knative
Add a Developer Handbook
This "handbook" is supposed to be a standalone manual which should help to understand the development flow of the client and also should make it easier for newcomers to ramp up.
Describe the feature:
A Developer Handbook should describe:
- How to get started with client development
- Described build.sh in detail
- How dependency are to be updated (see #58)
- How PR process works
- How E2E work and how they can be run locally
- How the code is organized (roughly)
- What the kn client API actually is
- How we deal with different version of Knative eventing & serving
- Deprecation process
- CLI option convention
- boolean options (wait, no-wait, ...)
- array options (traffic, ....)
- map options (env, label, ..)
- Mock Clients for Unit testing and how to use them
Part of #510
@abrennan89 I think such kind of documentation is best hosted in the client repo itself so that it is closer to the code itself. wdyt ?
If so, I would keep that issue within this repo and add the docs (markdown or asciidoc) to this client repo.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
This issue is stale because it has been open for 90 days with no
activity. It will automatically close after 30 more days of
inactivity. Reopen the issue with /reopen. Mark the issue as
fresh by adding the comment /remove-lifecycle stale.
I still believe that this is a good idea and helps in ramping up new users. AFAIK there is already an umbrella story somewhere that is about onboarding new developers in general.
For a first step a collection of markdown documents would be ok.