+1
Although I am probably one of those "put in episodic work only on
projects that interest me" people. Other major open-source projects
(e.g. SageMath and Plone) I have done pieces for have similar structures
and I thought they were useful.
Jonathan
On 8/1/20 6:23 PM, Oscar Benjamin 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.
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/CAHVvXxQ3bbJWOmHu7QYzQfnL_yO7WrE%2BzRoqsVZFkkyPA%2B%3DW_A%40mail.gmail.com.
--
Dr. Jonathan Gutow
Chemistry Department
UW Oshkosh
web: https://uwosh.edu/facstaff/gutow
e-mail: gu...@uwosh.edu
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 sympy+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/sympy/76ea0ef8-83fa-f2b3-826d-b47a9afa0339%40uwosh.edu.
