You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
These docs are generated from files in docs/ directory.
I don't have a data to back it up, but it is my impression that going through full Deno CI is discouraging contributions to manual; after all there are several pages on how to contribute to the repo and setting up dev environment is non-trivial. Additionally CI can take anywhere from 20 to 40 minutes.
Hereby I propose to move docs/ directory to a separate repository (deno_manual) with its own CI.
Here are pros and cons for this proposal.
Pros:
contributing will be significantly easier as the only requirement would be to have deno installed on your system (to run deno fmt)
CI will take less than 1 minute (quick development loop)
we could even enable auto-formatting in CI, so the PRs that are opened via "Edit" button in Github wouldn't fails more often than not
Cons:
another repo to maintain (would need to tag and release in unison with Deno release); although the maintenance cost should be marginal
All in all, I believe moving documentation to a separate repo will have a positive effect on the state of the manual as it would be trivial to contribute to it, which hasn't been the case lately in main repo.
Kinda off-topic but #11170 would immensely help to keep manual up to date by type-checking examples in codeblock (we already have this functionality for JSDocs, the issue is about adding ability to typecheck codeblock in markdown files).
The text was updated successfully, but these errors were encountered:
I don't have a data to back it up, but it is my impression that going through full Deno CI is discouraging contributions to manual; after all there are several pages on how to contribute to the repo and setting up dev environment is non-trivial...
This was my experience when first contributing to Deno. When I first found the project, I wanted to pick issues that were solely focused on the std library because it had nothing to do with Rust — however, much of the contribution steps/tasks had nothing to do with isolated TypeScript modules, and it was very confusing coming in fresh.
I don't have a data to back it up, but it is my impression that going through full Deno CI is discouraging contributions to manual; after all there are several pages on how to contribute to the repo and setting up dev environment is non-trivial...
This was my experience when first contributing to Deno. When I first found the project, I wanted to pick issues that were solely focused on the std library because it had nothing to do with Rust — however, much of the contribution steps/tasks had nothing to do with isolated TypeScript modules, and it was very confusing coming in fresh.
Thanks for the feedback Jesse, this is very useful opinion.
https://deno.land/manual is the "source for truth" and main documentation for Deno.
These docs are generated from files in
docs/
directory.I don't have a data to back it up, but it is my impression that going through full Deno CI is discouraging contributions to manual; after all there are several pages on how to contribute to the repo and setting up dev environment is non-trivial. Additionally CI can take anywhere from 20 to 40 minutes.
Hereby I propose to move
docs/
directory to a separate repository (deno_manual
) with its own CI.Here are pros and cons for this proposal.
Pros:
deno
installed on your system (to rundeno fmt
)Cons:
All in all, I believe moving documentation to a separate repo will have a positive effect on the state of the manual as it would be trivial to contribute to it, which hasn't been the case lately in main repo.
Kinda off-topic but #11170 would immensely help to keep manual up to date by type-checking examples in codeblock (we already have this functionality for JSDocs, the issue is about adding ability to typecheck codeblock in markdown files).
The text was updated successfully, but these errors were encountered: