Broad checklist of docs bits to work on
Nobody has claimed this yet.
- Dominant language
- Markdown
- Stars
- 238
- Forks
- 107
- Avg merge
- 1d 1h
- Merged PRs (30d)
- 2
Description
The documentation, in particular the one in Turing.jl itself, is in dire need of update given the amount of features and improvements we've made over the past year. In particular, the tutorials have lots and lots room for improvement.
A few things that come to mind immediately are the foollowing.
User-facing side:
-
Turing.predictfor predicting based on a givenchain. -
DynamicPPL.generated_quantities, similar to Stan's generated-block, which allows you to, effectively, capture the return-values of the model (i.e. the stuff inreturn ...) conditioned on achain. -
conditionanddecondition. There are now two ways to indicate whether a variable is to be considered an observation: passing the variable as an argument (the "old" way), or usingcondition/|(the "new" way). The latter has is, arguably, more intuitive, in addition to being much easier to work with programmatically. -
@submodel. A macro that allows you to use models within models. Makes it very easy to write modular models. -
logprior,loglikelihood, andlogjoint. Easy-to-use methods for evaluating the model in different ways. - fix and condition
Developer-side:
- Implementation of the LogDensityProblems.jl interface for a
@model. -
DynamicPPL.TestUtils. This is a sub-module of DynamicPPL that can be quite useful if one is developing features for Turing.
We will add more to the list as we go on, but for now this is a good starting point.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Review the Turing.jl documentation and tutorials, then use the unchecked condition/decondition, LogDensityProblems.jl interface, and DynamicPPL.TestUtils entries as the initial scope. Done means documenting those listed user-facing and developer-facing features and improving the tutorials, but the issue does not name specific files or tests.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- julia
- Domain
- documentation
- Issue type
- Documentation
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100