-
-
Notifications
You must be signed in to change notification settings - Fork 205
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Communication strategy #1054
Comments
Yeah I completely agree. I think what is important is to define a pattern, e.g. select a few features/optics/methods and write the sort of documentation we expect to get for the rest of the library. For example, it would be great to create a section on the website documenting all the some
Then we could reference this documentation in the code /** Description | Zoom into an `Option` but only if it is a `Some`
@see www.optics.dev/optics-builder#some
*/
def some[A1, B1](implicit ev1: A =:= Option[A1], ev2: B =:= Option[B1]): PPrism[S, T, A1, B1] = |
@kenbot do you have an idea how should we do this and communicate about it? |
I think my ideas are pretty aligned with yours. I'd say: Have "onion rings" of documentation levels, where each level n need not know anything about n+1. Something like:
|
I think the website, scaladoc, code/variable naming, import interface and compiler error messages all have to form one coherent, clearly stated communication strategy for 3.0 release. They all have to make sense with respect to each other, not just themselves.
The text was updated successfully, but these errors were encountered: