I have started a pull request for SymPEP 1. https://github.com/sympy/SymPEPs/pull/2.
Feedback is encouraged. This is still a draft, so everything I've written there can still be changed. I've based it largely on the NEP (NumPy Enhancement Proposals) process, with some changes. Aaron Meurer On Fri, Jan 22, 2021 at 3:11 PM Aaron Meurer <[email protected]> wrote: > > I started a repository for SymPEPs https://github.com/sympy/SymPEPs > > There's nothing there yet. I will start a discussion on the repo > either later today or early next week to discuss the SymPEP process > and drafting the SymPEP format (unless someone else beats me to it). > > Aaron Meurer > > On Mon, Oct 12, 2020 at 7:14 PM Nicolas Guarin <[email protected]> wrote: > > > > I also think that a new repo is the way to go. We don't want to have more > > (cognitive) load in the documentation. > > > > On Monday, October 12, 2020 at 6:49:02 PM UTC-5 Oscar wrote: > >> > >> I agree that a separate repo for SymPEPs is best. > >> > >> Once 1.7 is released I can try to draft SymPEP 1 soon for discussion > >> here to bootstrap the process. > >> > >> Oscar > >> > >> On Tue, 13 Oct 2020 at 00:22, Jonathan Gutow <[email protected]> wrote: > >> > > >> > +1 for a separate repo. > >> > > >> > I think that initially the default format for SymPEPs should be markdown > >> > as it renders well in github. Markdown has some serious limitations, so > >> > their may be reasons to change this later. > >> > > >> > Regards, > >> > > >> > Jonathan > >> > > >> > On 10/12/20 5:06 PM, Aaron Meurer wrote: > >> > > CAUTION: This email originated from outside of the organization. Do > >> > > not click links or open attachments unless you recognize the sender > >> > > and know the content is safe. > >> > > > >> > > > >> > > I'd like to restart discussion on SymPEPs. > >> > > > >> > > Here are the documents outlining the processes for PEPs, MEPs > >> > > (Matplotlib Enhancement Proposals), and NEPs (NumPy Enhancement > >> > > Proposals) > >> > > > >> > > https://www.python.org/dev/peps/pep-0001/ > >> > > https://matplotlib.org/3.1.1/devel/MEP/template.html > >> > > https://numpy.org/neps/nep-0000.html > >> > > > >> > > The MEP and NEP templates are both very similar to PEPs. > >> > > > >> > > So I think we should start with SymPEP 1, which would be the outline > >> > > of the SymPEP process. The first meta question that needs to be > >> > > answered, though, is where should SymPEPs live, and where should the > >> > > discussions on them take place? A natural place would be the wiki, but > >> > > I actually think the wiki isn't the best place. The wiki doesn't have > >> > > any discussion features, and it also doesn't have any way to do pull > >> > > requests. Also the wiki allows anyone to edit it without permission, > >> > > which might not be what we want for SymPEPs. > >> > > > >> > > So I would suggest either including them in the main SymPy repo, or > >> > > creating a new SymPEPs repo for them. Any preference on which would be > >> > > better? I think I would prefer a separate repo, unless we want to have > >> > > the rendered documents included in the SymPy documentation, in which > >> > > case that will be easier if they are in the SymPy repo. In either > >> > > case, I would suggest for the discussions for any SymPEP to take place > >> > > on issues or pull requests on the respective repo. > >> > > > >> > > Once we decide this, we can start with an actual start for SymPEP 1 > >> > > and the discussion of what it should look like. > >> > > > >> > > Aaron Meurer > >> > > > >> > > On Thu, Aug 6, 2020 at 2:08 PM Aaron Meurer <[email protected]> wrote: > >> > >> I think the documentation stuff is a bit off topic here. We can > >> > >> improve documentation and have SymPEPs. In fact, if improving > >> > >> documentation requires a large concerted effort, that could itself be > >> > >> a SymPEP. However, I will note that on this front: > >> > >> > >> > >> - We are participating in Google Season of Docs (GSoD, not to be > >> > >> confused with GSoC), which is a program that pays technical writers to > >> > >> work on open source documentation. The GSoD results will be announced > >> > >> in a couple of weeks, so watch this space. > >> > >> > >> > >> - I agree that we should have a concerted effort to improve > >> > >> documentation. A documentation sprint is one way. Getting funding to > >> > >> improve things is another. > >> > >> > >> > >> - We have a documentation style guide, which was developed as part of > >> > >> last year's GSoD. However, only a small subset of SymPy actually > >> > >> conforms to the guide > >> > >> https://docs.sympy.org/latest/documentation-style-guide.html. > >> > >> > >> > >> Aaron Meurer > >> > >> > >> > >> On Thu, Aug 6, 2020 at 1:48 PM Nikhil Maan <[email protected]> > >> > >> wrote: > >> > >>> > >> > >>> > >> > >>> On Thursday, August 6, 2020 at 9:39:43 PM UTC+5:30 > >> > >>> [email protected] wrote: > >> > >>>> A nice thing for a GSoD student to do would be to organize a > >> > >>>> documentation sprint. > >> > >>> > >> > >>> This sounds like a great idea. > >> > >>> > >> > >>> I also like the idea of SymPy Enhancement Proposals. Another project > >> > >>> that I think might benefit SymPEPs is Naman Gera's work on adding > >> > >>> control systems to SymPy. It will be a great place for folks who > >> > >>> would like to help with/continue this work in the future to find the > >> > >>> motivations and other details about the decision choices and future > >> > >>> plans. > >> > >>> > >> > >>> Looking at PEP-1 and seeing a large portion of the discussion in the > >> > >>> thread is regarding what kind of work should have a SymPEP and what > >> > >>> they should include, I think a good starting point for SymPEP-1 will > >> > >>> be to describe what are SymPEPs, why we are planning to add them, > >> > >>> what kind of changes should have a SymPEP, etc. Also, I like the > >> > >>> sound of SymEP and SymPEP. +1 to calling them SymPEP or SymEP > >> > >>> instead of SEP. > >> > >>> > >> > >>> Regards, > >> > >>> Nikhil Maan > >> > >>> > >> > >>>> Jason > >> > >>>> moorepants.info > >> > >>>> +01 530-601-9791 > >> > >>>> > >> > >>>> > >> > >>>> On Thu, Aug 6, 2020 at 5:32 PM Matthew Brett <[email protected]> > >> > >>>> wrote: > >> > >>>>> Hi, > >> > >>>>> > >> > >>>>> On Thu, Aug 6, 2020 at 4:10 PM David Bailey <[email protected]> > >> > >>>>> wrote: > >> > >>>>>> On 06/08/2020 00:47, Nicolas Guarin wrote: > >> > >>>>>> > >> > >>>>>> I agree that this would be good for the project but maybe it > >> > >>>>>> would be a good idea to polish the documentation a bit. Some of > >> > >>>>>> the pages in the wiki are somewhat outdated and they are on the > >> > >>>>>> first results in a web search. > >> > >>>>>> > >> > >>>>>> Assuming you are talking about the user level documentation, I > >> > >>>>>> very much agree. > >> > >>>>>> > >> > >>>>>> If you look up even the simplest function - e.g. Sin[] - in > >> > >>>>>> Mathematica, you get a simple explanation, some examples showing > >> > >>>>>> that it can be used with real numbers, and that it 'knows' about > >> > >>>>>> special arguments such as Pi/3. > >> > >>>>>> > >> > >>>>>> It shows you the power series about zero and a plot of the > >> > >>>>>> function. It also shows some properties of the function such as > >> > >>>>>> Sin[x] = -Sin[-x] etc etc. > >> > >>>>>> > >> > >>>>>> It also shows that Sin can be applied to complex arguments, or > >> > >>>>>> even to matrices, and that it can be applied to a high precision > >> > >>>>>> floating point number to deliver a high precision result. > >> > >>>>>> > >> > >>>>>> That same level of detail is provided for every function - right > >> > >>>>>> up to complicated functions like MeijerG. Remember that for > >> > >>>>>> functions such as that, the documentation is even more important > >> > >>>>>> because there are different conventions as to the order,sign, etc > >> > >>>>>> of the arguments. > >> > >>>>>> > >> > >>>>>> This might appear like overkill, but it means that wherever you > >> > >>>>>> start you will realise a Mathemaica function is far more than > >> > >>>>>> just a numerical function. This is also true for SymPy, but the > >> > >>>>>> information is harder to find. It is also easy to cut/paste from > >> > >>>>>> the documentation into your own code. > >> > >>>>>> > >> > >>>>>> Of course, the documentation is massively redundant, but I > >> > >>>>>> imagine that the documentation for each function or operation > >> > >>>>>> would not be written from scratch, but pulled from some kind of > >> > >>>>>> database of information. > >> > >>>>>> > >> > >>>>>> Obviously the SymPy documentation can't jump to the Mathematica > >> > >>>>>> standard overnight, but maybe a student could put together some > >> > >>>>>> sort of framework from which such documentation of the standard > >> > >>>>>> maths functions could be generated, and start the process off - > >> > >>>>>> then others could contribute information that would fit into the > >> > >>>>>> same scheme. > >> > >>>>>> > >> > >>>>>> I think that such documentation would make SymPy very much more > >> > >>>>>> user-friendly. > >> > >>>>> Just to say - that the Scipy Documentation Project took Numpy from > >> > >>>>> fairly woeful documentation, to very good documentation, in a few > >> > >>>>> months, and with a fairly small budget: > >> > >>>>> > >> > >>>>> http://conference.scipy.org/proceedings/SciPy2008/paper_5/ > >> > >>>>> https://ieeexplore.ieee.org/document/6879046 > >> > >>>>> > >> > >>>>> Cheers, > >> > >>>>> > >> > >>>>> Matthew > >> > >>>>> > >> > >>>>> -- > >> > >>>>> 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 [email protected]. > >> > >>>>> > >> > >>>>> To view this discussion on the web visit > >> > >>>>> https://groups.google.com/d/msgid/sympy/CAH6Pt5q%3DN_Vb0Z_yM2w8nBKwFFJu8UPBO3_A0c1UeWhAKDBX%3Dg%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 [email protected]. > >> > >>> To view this discussion on the web visit > >> > >>> https://groups.google.com/d/msgid/sympy/b977b777-52de-43af-81c9-445662ffef9bn%40googlegroups.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 [email protected]. > >> > > To view this discussion on the web visit > >> > > https://groups.google.com/d/msgid/sympy/CAKgW%3D6K114c9mbhXLVru4HCVB_M_-4wLdf7pHnz-ceHm97gAiQ%40mail.gmail.com. > >> > > >> > -- > >> > Dr. Jonathan Gutow > >> > Chemistry Department > >> > UW Oshkosh > >> > web: https://uwosh.edu/facstaff/gutow > >> > e-mail: [email protected] > >> > Ph: 920-424-1326 > >> > > >> > -- > >> > 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 [email protected]. > >> > To view this discussion on the web visit > >> > https://groups.google.com/d/msgid/sympy/680e649c-f869-dcb4-f17f-7f5e977a17cd%40uwosh.edu. > > > > -- > > 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 [email protected]. > > To view this discussion on the web visit > > https://groups.google.com/d/msgid/sympy/bd536574-b2c3-4cd8-983f-c91b3dbd4ffcn%40googlegroups.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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/sympy/CAKgW%3D6KGgVuXP6%3DQsbrpJQxgYiRPehrGRmcfvc1%3DK567CsCpVQ%40mail.gmail.com.
