Outline

Please add an outline of the top-level sections of what you feel the paper should be, with how many pages each section should be. The total pages should not add to more than 18 (the references will take a couple of pages).

The length of content in the supplement doesn't matter. This is just about the paper itself.

If you think a section should be there that isn't listed, add it.

Proposed outline

Introduction:

• Aaron: 1
• Jason: 1
• Anthony: 2

Community:

How the community and development model contribute to the uniqueness of SymPy.

• Aaron: 0.5 At most. Can also be part of the introduction (in which case, 0).
• Jason: 1 I'd like us to show how we differ than other SciPy sub-communities in terms of number of contributors that have substantial number of commits and any other unique aspects that we have. I also would like to see this quote by Anthony expanded "the accessibility of the codebase and the community model allow SymPy to rapidly respond to the needs of the community of users without the knowledge or consent of the original developers".
• Anthony: 0.5, as a subsection of the introduction

SymPy's Role in the Scientific Python EcoSystem:

Explains how SymPy uses and is used by other software packages in the "SciPy Stack".

• Jason: 1
• Anthony: 0.5, as a subsection of the introduction

Architecture (including numerics):

Explanation of the main symbolic and numerical architectural design of SymPy.

• Aaron: 7 I more or less am happy with the architecture as it stands, length-wise.
• Jason: 4 I think that besides the core architecture this should be pushed to the supplement.
• Anthony: 8 - 10, I see this as the main thrust of the paper

Features:

Explains some of the main features of SymPy and shows some examples of use.

• Aaron: 5 What is there is good, but it needs to be cut down.
• Jason: 5 If this is included, I can see 5 pages, but this seems more appropriate (and already exists) in our documentation.
• Anthony: 3

Domain specific features:

Explanation of the capabilities of various domain specific packages in SymPy.

• Aaron: 1 No more than 1. Possibly less.
• Jason: 0.25 Any details should be in the supplement. This should simply mention that we have domain specific packages in SymPy, why, and very briefly what they are.
• Brian: 1 Some of the domain specific stuff is really important, so we need to give some room for this
• Ondřej: 1-2 It is important to have this
• Anthony: 1

Uses of SymPy:

Software packages that use SymPy and projects that use SymPy.

• Aaron: 2
• Jason: 0 I broke this up into "Software projects that use SymPy" and "SymPy's Impact in Research, Education, and Industry" below.
• Anthony: 0, mention within the intro or conclusion

Software projects that use SymPy:

Says that SymPy is used as a library and lists software projects that use SymPy in this fashion.

• Jason: 0 This could be a one or two sentences, maybe mentioning a couple of main ones like Sage, in the main text and the extenisive list should be in the supplement.
• Anthony: 0

SymPy's Impact in Research, Education, and Industry:

Highlights examples of SymPy uses in research, education, and industry

• Jason: 4 Some intro and about one page per domain.
• Anthony: 0.5, mention as part of the intro.

Comparison with other CASs:

Shows how SymPy's features, performance, and usability compare to other CASs.

• Aaron: 0 / 1.5 I think based on the content we currently have, we should put this in the supplement. If we can get a more balanced comparison (more than just Mathematica), we can include it, but I'd say at no more than 1.5 pages.
• Jason: 2 I'd like to see more work on this section and inclusion of one or two other packages. Maybe a table of comparisons.
• Anthony: 0.5, mention only in broad strokes in intro

Conclusion and future work:

• Aaron: 0.5
• Jason: 0.5
• Anthony: 2, should be about the same length as the intro

Current paper outline

Introduction: 1

Architecture (including numerics): 7

Features: 7

Domain specific features: 1.5

Other projects that use SymPy: 1

Conclusion: 0.5