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. On Saturday, August 1, 2020 at 6:22:49 PM UTC-5 Oscar wrote:
> Hi all, > > I've been thinking for some time that there should be more > coordination amongst sympy contributors and more involvement with the > broader sympy community in the general direction that sympy takes. I > want to propose the idea of SymPy Enhancement Proposals (SEPs) > analogous to numpy's NEPs and core Python's PEPs. > > The Python PEP process is explained in PEP 1 (the details would be > different for sympy): > https://www.python.org/dev/peps/pep-0001/ > > Background > ------------- > > At the moment most discussions around the general direction of sympy > take place on github and are spread across many different issues and > pull requests. The only way to really keep track or to engage with the > discussion is by following all traffic on the sympy github repos. > That's what I personally do (I get an email every time anyone posts > anything on any issue or pull request on any of sympy's repos) but > that's only really manageable for someone who is very actively engaged > with contributing to or following sympy development. That means that > the broader sympy community is not really included in most of the > discussions around the direction of sympy development. > > Also there is a lack of higher-level coordination amongst > contributors. To me it seems that most work in sympy is piecemeal with > different contributors working on whichever problem they personally > care about without necessarily understanding the broader issues across > the codebase that are affected by the work that they do. SymPy > currently operates on a "consensus" model that once all people > involved in a discussion are agreed then a change can be made but it > is often not possible for many people to follow a particular > discussion. In practice this means that most changes are agreed by a > small number of people even if they have a wide impact. > > One particularly limiting aspect of this is that there isn't really > any forum in which broader discussions about the higher-level > direction of sympy development take place. I think that right now > there are a number of major obstacles to further progress in sympy > that need to be dealt with by broad community discussion. This should > involve both downstream users and contributors (new, old, active and > inactive). Examples would be the future of the new and old > assumptions, new implementations of matrices, extensibility of the > core of sympy, fixing major problems like the 2-arg Rational-Add Mul, > fixing the evaluation model to get rid of evaluate=False, and many > more. All of these are changes that would involve a substantial amount > of work across the main sympy codebase and that would involve some > compatibility breaks. They are all needed (IMO) for the future > development of sympy though. > > I think that maybe numpy was in a more similar state some years ago > but has now upped its organisational game and has many NEPs addressing > long standing problems and even weekly online meetings amongst > particularly active contributors. By contrast sympy has no > organisational arrangements to facilitate coordination of development > as far as I can tell. > > A Python PEP or numpy NEP is a document that proposes a change to > Python/numpy but also explains bigger picture issues and crucially is > presented to a wide audience for discussion. Once approved the PEP > serves as a record of what was agreed at the time with a rationale for > the changes as well as a prescriptive high-level explanation of what > the changes will be. SymPy should have SEPs for the same reason that > Python has PEPs: > > 1. A PEP makes it possible for many more contributors/users to take > part in a discussion > 2. The discussions around a PEP can improve the resulting proposal by > taking in as much feedback as possible. > 3. Having the discussion (and documenting it) engages the broader > community so that the reasons for changes in sympy are understood. > 4. After a PEP is agreed then it is possible to refer to it in future > as an explanation/justification for doing part of the work to > implement the PEP. > 5. When a PEP has been fully implemented it serves as a historical > document motivating the reasons for the changes made. > > A PEP serves a different purpose from documentation which explains the > code as it is at a given time. By contrast a PEP focuses on the > discussion around the changes to be made and the reasons for those > changes (at that time). > > > > Idea > ---- > > The idea I want to propose is that sympy should have a process for > proposing, discussing, approving and amending documents known as SymPy > Enhancement Proposals (SEPs) analogous to Python's PEPs. There should > be a repo `sympy/seps_repo` to host these documents. The main > discussion should take place here on the mailing list. Some SEPs can > be informational and others can be proposals for changes. > > In core Python a PEP is generally expected to have a full working > implementation at the time of acceptance. I expect that for sympy it > will make more sense for a SEP to represent something aspirational > that is not achievable by a single contributor in a short period of > time. Rather the SEP should define the general direction in enough > detail that many different contributors can implement parts of the > proposal. It would probably make sense for a SEP to have a section > describing the extent to which it has been implemented. If we had a > few SEPs that were accepted and that were defined in sufficient detail > then it would be a lot easier for new contributors to implement those > changes knowing that they were already agreed and specced. We could > e.g. encourage GSOC projects that implement SEPs. > > The process could be something like: > > 1. Post a SEP draft on the mailing list and open a PR against the SEPs repo > 2. Discuss on the mailing list and the repo > 3. Amend the draft and repost etc until discussion converges > 4. Some sort of decision is made... > 5. The SEP is accepted but needs to be implemented > 6. Implementation happens over some time probably by multiple contributors. > 7. The SEP can be discussed or amended subject to discussion on the > mailing list (if issues arise in implementation) > 8. Once the SEP is fully implemented it is finalised and not edited > further. > > > What do people think of this idea? > > -- > 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/f8eb5728-7ccc-4a3a-bee8-96c274630f75n%40googlegroups.com.
