Hi Lauren. We are excited to have you working with us!

On Thu, Aug 8, 2019 at 10:18 AM Lauren Glattly <laurenglat...@gmail.com> wrote:
>
> Hi Sympyers!
>
> Thanks for the introduction Jason! I'm very excited to be participating in 
> the inaugural Google Season of Docs with SymPy. I've been working as the 
> technical copy editor for Astropy which has been a great experience all 
> around, so I am delighted to be expanding my network within the open source 
> community. I'd love to start hearing from users about what kinds of 
> consistency issues I should be on the lookout for as I start to familiarize 
> myself with SymPy's docstrings.

Most things are listed on the issues that are linked on the ideas page
https://github.com/sympy/sympy/wiki/GSoD-2019-Ideas

The SymPy docstrings, as you are probably already aware, have to major
forms. The docstring itself is written in RST (for example,
https://github.com/sympy/sympy/blob/ecd30247fd216432fb1b51020fa4c741ebe4c5af/sympy/solvers/solvers.py#L454),
and it is rendered as HTML on our docs website
(https://docs.sympy.org/latest/modules/solvers/solvers.html#sympy.solvers.solvers.solve).
Both forms should be readable, because people often get help for
things in interactive Python sessions, using help() or ? in Jupyter,
which gives the plain text form. The numpydoc Sphinx extension renders
special headers in the docstring in certain ways. For instance, a list
of functions under the "see also" header get rendered as a list of
links to those functions' documentation.

The biggest issues with inconsistencies, I would say, come from the
HTML side. A large issue is that people don't always look at the
rendered HTML, and things that look just fine in plain text don't look
good in HTML. Some example issues

- SymPy currently has Sphinx configured so that `text` between single
backticks renders as LaTeX math. In RST, ``text`` between double
backticks renders as code. However, most people are used to Markdown
from commenting on GitHub as well as other places, where single
backticks generate code. The result is that there is a lot of text in
docstrings that is rendered as LaTeX math when it shouldn't be. It
also doesn't help that there isn't a clear style guide to delineate
when the two forms should be used (it gets ambiguous because you can
represent mathematical expressions with SymPy in code).

I would actually like to change our Sphinx so that `text` formats as
code, and :math:`text` is required to get LaTeX math. However, this
will require going through every docstring in SymPy and fixing every
use of single backquotes. I think we can write a script to do this
automatically, but that doesn't solve the problem that a large portion
of them are incorrectly rendered. See
https://github.com/sympy/sympy/issues/13519

- A related problem is that sometimes the LaTeX math is not formatted
correctly. As I noted, not everyone takes the time to look at the
rendered Sphinx for their documentation (if you have any thoughts on
how to improve this let us know). For example, sometimes people will
write "a*b" in a LaTeX formula. The * is necessary in code, but in
LaTeX, multiplication should be written as just "ab".

- Some formatting, such as ``code``, is not always used when it should
be. Anything that references a variable name should be formatted as
``code``, for instance.

- Every docstring should have the predefined headers I mentioned above
(see also, examples, etc.), if possible. I don't know if it should
necessarily be your responsibility to write them for the docstrings
that are missing them, since that requires technical knowledge of the
specific functions. However, it will be good to have 1) an official
guide on what should be there, and 2) a way to see which docstrings
are missing what.

- I think a big thing that is missing is formatting of argument
parameters. For instance, in the solve() docstring I linked to above,
all the argument parameters are documented, but the formatting is
haphazard. Other functions are missing them entirely. We should have a
consistent formatting style for these, perhaps using the numpydoc
format that already exists.

Aaron Meurer

>
> Looking forward to working together this fall!
>
> Lauren
>
> On Thu, Aug 8, 2019 at 10:53 AM Jason Moore <moorepa...@gmail.com> wrote:
>>
>> Sympyers,
>>
>> We are happy to announce our first participation in Google's new "Season of 
>> Docs" with Lauren Glattly. Lauren's proposal was selected from 12 
>> applications. She is a technical writer by trade and will be working on 
>> consistency and improvements to our docstrings. We are now starting the 
>> community bonding period. Please welcome Lauren and help her get familiar 
>> with the project as well as provide your thoughts on what needs to be 
>> improved with our documentation. She will be working with us for 3 months 
>> (similar to GSoC) starting September 2nd.
>>
>> You can learn more about Lauren at her website: http://www.laurenglattly.com/
>>
>> We'd also like to thank all applicants for their submissions.
>>
>> Jason
>> moorepants.info
>> +01 530-601-9791
>
> --
> You received this message because you are subscribed to the Google Groups 
> "sympy" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to sympy+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sympy/CANA%2BcPuSidmXzVWRveRAfpc4i3BvumOZxLw7OA1JXXwL3DRA%3Dw%40mail.gmail.com.

-- 
You received this message because you are subscribed to the Google Groups 
"sympy" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sympy/CAKgW%3D6Jzj_RB6fCAbVpNuVd-XzmMucN1xXQ7Fm0hjOU%2B5bXZ1A%40mail.gmail.com.

Reply via email to