-
-
Notifications
You must be signed in to change notification settings - Fork 7.9k
DOC: add mission statement #20220
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
DOC: add mission statement #20220
Conversation
7dc64a6
to
f29c424
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just a few wordsmithing suggestions. Looks great!
doc/users/project/mission.rst
Outdated
Matplotlib Mission Statement | ||
============================ | ||
|
||
The mission of the Matplotlib developer community is to develop, maintain, and |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe split in two sentences: Matplotlib is… The Mission of the Matplotlib community is …
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@timhoffm do you like Jody's edits?
Co-authored-by: hannah <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
placeholder for longer response or discussion on call
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's close to ready, but I have some suggestions for consideration.
I think this is ready for a final review. I would like to get put this on the agenda for next weeks dev call. I am going to assert the merge conditions for this is consensus from the steering council. |
The lens I think we should use to read this through is answering the questions:
I think this statement for our own internal guidance for "what it is we do here" and for people who what to start working on the project, not an external facing document for users to determine if using this library is "for them" or not. Nor does this need to enumerate every activity we are going go do in support of the mission (keeping the CI up is critical, but also has no place in the mission statement!). Similarly, a clean and consistent API or complete well written documentation are things we do to accomplish the mission, but are not the purpose in and of themselves. Being a historically and currently primarily volunteer organization we have all brought our own intrinsic motivations for why we do things and each make decisions about what we spend our time on to align with those internal motivations, however now that we have funding (and plan to get more) we need to be able to articulate what our mission is. I was motivated to articulate this now (well, last Nov) by training from CZI about how to develop and maintain an organizational-level strategic plan. The first prerequisite for any of that work is to agree what the mission is! [edited to add missing word] |
doc/users/project/mission.rst
Outdated
|
||
* Support all users of the Scientific Python Ecosystem; | ||
* Produce high-quality raster and vector formats output; | ||
* Be embeddedable in graphical user interfaces for application development; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do we want to say something about web and/or interactivity? These are not our strong sides right now, but we should discuss whether that should be our goal.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GUI application implies interactivity, though the word could be inserted to make it explicit. I think that better interactivity in web apps like Jupyter notebook is important. Maybe modify to "...application development, standalone and on the web."
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
After fixing a couple typos and addressing Tim's comments, it will be ready.
doc/users/project/mission.rst
Outdated
|
||
* Support all users of the Scientific Python Ecosystem; | ||
* Produce high-quality raster and vector formats output; | ||
* Be embeddedable in graphical user interfaces for application development; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
GUI application implies interactivity, though the word could be inserted to make it explicit. I think that better interactivity in web apps like Jupyter notebook is important. Maybe modify to "...application development, standalone and on the web."
Co-authored-by: Jody Klymak <[email protected]>
|
doc/users/project/mission.rst
Outdated
The Matplotlib developer community develops, maintains, and supports Matplotlib | ||
and its extensions to provide plotting tools for the Scientific Python | ||
Ecosystem. We judge our success based on how effectively we enable our users, across | ||
scientific, industrial, commercial, and educational domains, to achieve their |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
scientific, industrial, commercial, and educational domains, to achieve their | |
academic, industrial, commercial, and educational domains, to achieve their |
@noatamir pointed out that "scientific" is the odd-one-out in this sentence and "academic" is a better word for what is meant.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The suggested change leaves out NASA, NOAA, USGS, etc. Is there a concise way to include them? Or are we trying to do too much enumeration of specific categories? Maybe just leave out the whole list, and leave it at "enable our users to achieve their goals". That leaves the domain specification to "Scientific Python Ecosystem"; maybe that is enough.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm also not sure in that context what the difference between "academic" and "educational" is.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As someone who sits in a institution that is in that categories (in the US they tend to be called Federally Funded Research and Development Centers (FFRDC)), we are used to the ambiguity and will self-identify as whichever of the other categories suits us best at the time ;) We could reference FFRDC but that would miss our peer institutions in other countries (and is super jargonny).
There is some aspect of on-label and off-label uses of Matplotlib. Our heritage is for scientific plotting (going back to John's EKG plots) and a majority of our developers are trained in some sort of science, and a bulk of the (maybe over) specialized plotting we have is driven by the needs of scientific visualization. That we have also been used by a (wide) variety of people outside of the domains that our developers work in is a testament to the library and is great! One of the best things about open source is that our users do things with the code that the core developers could not have imagined. However, we can not support all domains equally; part of it is just the expertise we have in the core team (I think mpl-finance is a good example here that is much better off with Daniel as a stand-alone project) and because there may be conflicting needs/expectations and some use is should be considered "intended" and some "we are happy it works".
Some of this is very easy to do: "please implement an email client" -> "no, obviously out of scope".
Some is a bit harder, but still easy: "This API makes it hard to make (intentional) art with Matplotlib " -> "cool you are making art, but the purpose is to be a plotting library so we will not change the API"
Some are super subtle : "if I drop integer coded catagoricals into imshow and use interpolation I get fractional values" -> well, that is a bit of a miss-use of imshow
because it implicitly assumes the values are continuous not discrete. do we need a new function, make imshow (yet more) complex, or is no-norm the solution here?
That is all a very long winded way of saying I think that it is important that we scope the intended application down from "anyone who installs the library and has a story about how they want to use it".
Another aspect that I want to make sure we do not lose is a sense that Matplotlib is always (well intended to be) used as a means to and end, not and end it self. There is some reason (be it understanding some science measurement, scheduling operations, looking at revenue over time, looking at survey results, looking at market data, ....) that the user is making a plot. Our goal is not to be the perfect platonic plotting library, but rather to be a tool in service of whatever it is our users are actually doing (I also think that this is the case for a vast majority of software).
Put another, to paraphrase Charity Majors "9s design does not matter if users are not happy" . We can not make all users happy all of the time so we should identify which users / applications we intend to make happy to help us with triage / decision making.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"enable our users to solve problems in their scientific, educational, and operational domains."
doc/users/project/mission.rst
Outdated
Ecosystem. We judge our success based on how effectively we enable our users, across | ||
scientific, industrial, commercial, and educational domains, to achieve their |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ecosystem. We judge our success based on how effectively we enable our users, across | |
scientific, industrial, commercial, and educational domains, to achieve their | |
Ecosystem. We judge our success based on how effectively we enable our users to achieve their |
doc/users/project/mission.rst
Outdated
<project_history>` Matplotlib should: | ||
|
||
* Support all users of the Scientific Python Ecosystem; | ||
* Produce high-quality raster and vector format outputs; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sorry for dropping in late in the discussion (thanks to @story645 for pointing me to it as well). Perhaps it is worth mentioning "publication quality plots" in there as well?
xref to pandas mission
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm sure there's plenty of improvement to make this more of a "mission" statement, but I'm happy with how it reads now.
Does no-one want to hit the button; might be the most approvals ever? I don't see anything in the notes, so I'm going to do it. |
PR Summary
This is a (very) rough draft of a follow on to contents of history.rst which lays out what JDH understood Matplotlib to be when it started that lays out what we think Matplotlib should be going forward.