update CONTRIBUTING.md

CONTRIBUTING.md

@@ -2,40 +2,43 @@
 
 Contributions to MLJ are most welcome. Queries can be made through
 issues or the Julia [slack
-channel](https://julialang.org/slack/), #MLJ. 
+channel](https://julialang.org/slack/), #mlj. 
 
 - [Road map](ROADMAP.md)
 
 - [Code organization](ORGANIZATION.md)
 
-- Issues: Currently issues are split between [MLJ issues](https://github.com/alan-turing-institute/MLJ.jl/issues) and issues in all other repositories, collected in [this GitHub Project](https://github.com/orgs/JuliaAI/projects/1).
+- Issues: Currently issues are split between [MLJ
+  issues](https://github.com/alan-turing-institute/MLJ.jl/issues) and
+  issues in all other repositories, collected in [this GitHub
+  Project](https://github.com/orgs/JuliaAI/projects/1).
 
 
 ### Conventions
 
-We follow
+Most larger MLJ repositories follow
 [this](https://nvie.com/posts/a-successful-git-branching-model/) git
-work-flow and, in particular, ask that **all pull requests be made to
-the`dev` branch** of the appropriate repo, and not to `master`. This
-includes changes to documentation. All pull requests onto `master`
-come from `dev` and generally precede a tagged release.
+work-flow. In all cases please make **all pull requests to the default
+branch** of the appropriate repo (branch appearing on the repo's
+landing page). This is `dev` for larger repos, and `master`
+otherwise. This includes changes to documentation.
 
 Contributors are kindly requested to adhere to the
 [Blue](https://github.com/invenia/BlueStyle) style guide, with line
-widths capped at 80 characters.
+widths capped at 92 characters.
 
 
 ### Very brief design overview
 
 MLJ has a basement level *model* interface, which must be implemented
 for each new learning algorithm. Formally, each model is a `mutable
 struct` storing hyperparameters and the implementer defines
-model-dispatched `fit` and `predict` methods; for details, see
-[here](docs/src/adding_models_for_general_use.md). The general user
-interacts using *machines* which bind models with data and have an
-internal state reflecting the outcomes of applying `fit!` and
-`predict` methods on them. The model interface is pure "functional";
-the machine interface more "object-oriented".
+model-dispatched `fit` and `predict`/`transform` methods; for details,
+see [here](docs/src/adding_models_for_general_use.md). The general
+user interacts using *machines* which bind models with data and have
+an internal state reflecting the outcomes of applying `fit!` and
+`predict`/`transform` methods on them. The model interface is pure
+"functional"; the machine interface more "object-oriented".
 
 A generalization of machine, called a *nodal* machine, is a key
 element of *learning networks* which combine several models together,