Hi, I read the original post and I think the idea of introducing SEPs seems to be really useful. Since, I am quite involved with `stats` module and was thinking to add some new features to it to make it more powerful and useful to the people working in the area of statistics. I wanted to know whether it will be possible to propose new features via SEP or more precisely, can SEPs initially have requirements and expectations, and then later on after community discussion, SEPs can be changed and more details can be added. I also believe that there many similar issues in the issue tracker and they can be grouped together into a single SEP. In fact, once we do that, instead of having GSoC ideas list, students should be encouraged to make proposals for implementing the SEPs they are interested in.
With Regards, Gagandeep Singh Github - https://github.com/czgdp1807 LinkedIn - https://www.linkedin.com/in/czgdp1807 On Sun, 2 Aug, 2020, 10:45 PM Oscar Benjamin, <oscar.j.benja...@gmail.com> wrote: > On Sun, 2 Aug 2020 at 14:54, Jonathan Gutow <gu...@uwosh.edu> wrote: > > > > I think the Plone PLIP implementation is the best of the two. Here's my > brief understanding (details at: > https://docs.plone.org/develop/coredev/docs/plips.html): > > > > PLIPs are implemented as issues in the github repository. This > facilitates conversion to a simple bugfix or small enhancement if review > determines that is more appropriate. > > PLIPs are primarily for changes that will have significant impact on the > codebase, API or end user experience. > > The project is large enough that they have a number of committees that > oversee things. One of them oversees PLIP review on the community > discussion groups and makes the final decision of whether to approve or > deny the PLIP. > > The issue is used to produce a final version of the PLIP with a detailed > description of the desired outcome, how it will be implemented (not > line-by-line changes) and the risks/potential problems associated with the > implementation. The expectation is that all PLIPs will have some negatives > and will only be approved if the community decides that the positives > outweigh the negatives. > > > > Based on my brief experience with SymPy, I think an oversight committee > for SIPs might be more than the current SymPy community can manage. > Otherwise, I think the model used by Plone makes it easy for people to > propose significant changes and get a clear community review. > > I think that you are probably right. I was thinking more just that > SEPs (SIPs?) could be discussed here on the mailing list rather than > on github to involve a wider audience. That's a feature of PEPs/NEPs > that isn't described in the PLIPs guidance, presumably because the > process involves a regular oversight committee. > > It's interesting to see that in the Plone model there is a very clear > separation between specification and implementation. The guidance > makes it clear that implementation is not expected to begin until some > agreement is reached on the changes to be made. That is I think what > sympy needs as well. > > > Oscar > > -- > 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/CAHVvXxTGGT6L_vfFVtbH2T%3D-PsxdOyvJUe3cXojDM3ba%2BDcEtA%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/CAAvS0gUnr7wRgRkPtDMB1Xf_PTuQ0XW8WXPOmPQcTBVB0Gp2Tg%40mail.gmail.com.
