# January 2020
###### tags: `2020 dev call`
Call co-ordinates: Mondays @ 15:00 Eastern US time (UTC -05:00) https://zoom.us/j/384435716

Previous Notes: [2020 Meeting Agenda](/zljR-pZrQ0O5J_j4NZ-9yw)
Archive: [matplotlib/ProjectManagement](https://github.com/matplotlib/ProjectManagement)

# Needs Discussion At Some Point
- GSOC
- named roles
- roll-off procedure
- blog PR/merge guidelines
- mission statement/vision

# Feb: [February 2020](/4zWKhuLXQ16Y_oUfi9hnKA?both)

- https://github.com/matplotlib/matplotlib/pull/14916

# 27 Jan

- [x] https://github.com/matplotlib/matplotlib/pull/15440 (rcParams for window raise)
- [ ]These two together (`axline`)
- https://github.com/matplotlib/matplotlib/pull/15330
- https://github.com/matplotlib/matplotlib/pull/16337
- [x] https://github.com/matplotlib/matplotlib/pull/16255 (side bar versions)
- [x] Decision on https://github.com/matplotlib/matplotlib/pull/16178 (mutiple labels for `plot()`)
- [ ] https://github.com/matplotlib/matplotlib/pull/16005#issuecomment-578400682 (artist handles in x/y labels)
- [ ] https://github.com/matplotlib/matplotlib/pull/16347 (too sketchy with warnings?)

## Notes

### 16255: Sidebar version info:
- https://github.com/matplotlib/matplotlib/pull/16255
- merged

### 15440: rcParams to raise window
- https://github.com/matplotlib/matplotlib/pull/15440
- window management/events system needs documentation. But not for this PR...
- mpl hides a lot of complexity from user, makes hard to create issues,
- orthogonal to user needs, maybe doesn't need it's own project?
- probably mostly for people who understand windows managers. Two raising cases mutually exclusive.
- https://github.com/matplotlib/matplotlib/pull/4779 <- attempt at more complete interactive docs
- https://matplotlib.org/tutorials/introductory/customizing.html#a-sample-matplotlibrc-file <- comments in rcparam template do take it into the docs
- To Do: author needs to add what's new to right place
- adding whats-new different than api changes?
- api changes is automated: https://github.com/matplotlib/matplotlib/pull/15158
- what's new is hand crafted 'cause it's more press release

### 16178: labels to all lines plotted in `plot`
- https://github.com/matplotlib/matplotlib/pull/16178
- have to vectorize all the things if vectorizing one thing?
- currently all kwargs are scalers applied to all data
- plots, markers, colors, linestyles
- stackplot already supports this behavior:
- https://matplotlib.org/gallery/lines_bars_and_markers/stackplot_demo.html#sphx-glr-gallery-lines-bars-and-markers-stackplot-demo-py
- this behavior makes sense for the plot type as y-input is inherently 2D
- all other kwargs are passed down to each fill between as scalars
- feature is nice on user level, complicate on library level
- special case each keyword
- colors is complicated 'cause can be list of RGB, HTML, or named colors
- should deprecate open ended `plot(x1, y1, x2, y2, ...)`
- labels as special case 'cause can't put labels into property cycle the way colors, linestyles, etc...
- cycler is obscure/hard to handle/hard to remember
- User: lots of lines from 2D array, quickly label them
- opt 1: support w/ labels
- opt 2: save line object & pass into legend
- opt 3: autofind handlers/seperates labels from data
- ```plt.legend(['abc', 'efg', 'hij'])```
- ```ax.legend(['abc', 'efg', 'hij'])```
- seperating data from metadata & aesthetics:
- labels are semantically linked to data
- cycler/aesthetics aren't inherently semantically linked
- bokeh vectorizes all the mappings
- concern about `ax.plot(x, [5, 6, 7], x, [1, 2, 3], label=['cats', 'dogs'])`
- as the PR is this will fail
- but user will probably want that to work :disappointed:
- long discussion about the right level to do the broadcasting at (the "pair level" and the "Nd level"). You can get multiple lines out of `plot` by passing in `ax.plot(x, [[], []])` (ND) or by passing `ax.plot(x, [], x, [])` (pair). The "pair" level broadcasting is handled in `__call__` on the arg parser helper class `_process_plot_var_args` and the ND level is handled in `_plot_args`.
- One way to do it is as implemented in the PR (the iterable of labels is passed down un-changed to each pair). This means that each ND set must be the same length and you will end up with "pair" number of lines with the same label
- another way to do it is for the labels to be the "flattened" list so if you have two "pairs", one of length 3, the other of length 5, then `label` must be a single string or of length 8
- another way to do this is to in the same 3 + 5 case have `label` be a list of lists (the outer length would be 2 and the inner lists would be 3 and 5 long respectively).
- none of these are great but none is obviously wrong.

**decision** :
- good feature, but limit to only being usable when one "pair" is passed in to avoid the stacking issues discussed above
- in general we probably do want to allow all of the style parameters to be broadcast, but that would be a huge API change (as we would have to invent a general version of color mapping, adjust return type stability, etc)
- but labels are important enough that they are worth special casing and putting in now

# 20 Jan
## Agenda
- Discourse 3rd party package section
- https://github.com/matplotlib/matplotlib/pull/16250 (blocking from 3.1.3, 3.2.0rc)
- https://github.com/matplotlib/matplotlib/pull/15065 (requested on gitter)
- https://github.com/matplotlib/matplotlib/pull/16255 (can tweak after 2.2.5 tag)
- https://github.com/matplotlib/matplotlib/pull/16226 (can tweak after 3.2.0 tag)

## Notes

### Discourse -> third party (i. Cartopy)
- many third party packages don't have user forums
- 3rd party packages:
- [x] make a top level section, give projects subsections: https://discourse.matplotlib.org/c/development/3rdparty/18
- default is stuff that intersects like mpl devs
- ask packages if they want a section?
- Make sure they have a contact person
- they can reply to about post in section: https://discourse.matplotlib.org/t/what-are-3rd-party-packages/20666
- [x] moved https://discourse.matplotlib.org/c/development/3rdparty/

### 16226: website front page
- @hannah will review in the next couple of hours
- [x] follow up with @Dora and @Tom on frontpage redesign timeline
- don't want frequent UI/UX changes on front page but want to improve stuff

### 16255: Version numbers in sidebar
- wants backported into 2.25
- which browsers need to be supported?
- doesn't work on ie11

### 16250: zero-len path intersect
- just needs minor tweaks (check zero len)

### 15065: step='between' draw style...
- loop in @importanceofbeingernest to sort out resolution
- simplify
- don't change Line2D to add a new drawstyle. Either do without a base class or make a new base class on top of Line2D. (Composition)
- still keep ability change x & y data (will require a bit of engineering)
- maybe no 'edges' and not go to zero implicitly
- `ax.step` could return a new type...
- new method? or a new class w/o back compatibiltiy concerns...

# 13 Jan
## Agenda
- pcolor
- merge-up updates

## Notes

### pcolor
- https://github.com/matplotlib/matplotlib/pull/9629
- 3 ways to match (x, y) and color
- edges and centers (expect edges to be bigger by 1)
- centers-center (the edges are infered by putting them between the centers)
- corner-corner (as in gourand shading)
- pcolormesh is at the core is edge and center
- but lots of data is center-center
- people have been incorrectly assuming that pcolormesh in center-center and we silently do something defendable but not want anyone actually wants
- already have the corner-corner case covered via the 'shadding' kwarg

Decision:
- add a kwarg to control which of the 3 layouts the input is coming in as
- re-sample internally as needed
- throughly document
- start warning if the sizes are miss-matched in the default case (eventually raise)

### Postdoc/Programmer
- resumes being evaluated

### tick labels
- bunch of issues recently with `get_xticklabels` and friends
- related to a change in how we manage the visibility state and if they get returned
- previously would only return if `label1On` was set
- now only returns if visible
- alternative 1
- keep filtering, add docs on how to get them all
- alternative 2
- never filter
- *alternative 3*
- add kwarg to filter or not
- leave default as filter

Consensus is alternative 3 (@timhoffman will take on)

### other PR reviews
- https://github.com/matplotlib/matplotlib/pull/16189 (merged)
- https://github.com/matplotlib/matplotlib/pull/16203 (noted, @tacaswell will review)
- https://github.com/matplotlib/matplotlib/pull/16039 (merged)
- https://github.com/matplotlib/matplotlib/issues/16163 (will be closed)

# 7 Jan
## Agenda
- Meeting time- currently conflicts with @Jody K , @Eric F teaching schedule
- releases
- 3.2.0rc3,
- 3.1.3
- 2.2.5 (the last one!)
- CZI is starting!

## Notes

### Reschedule meetings
- move to Mondays 3:00 EST to accommodate teaching

### Releases
- Need to find a volunteer to help with releases
- email list to ask for ~~tribute~~ volunteer?
- maybe put this on the plate of RSE?
- should look into adopting some more automatic tooling
- reaver?
- need to automate: https://matplotlib.org/devdocs/devel/release_guide.html
- targeted releases seem good

### 15961: Opinionated setting up dev env

https://github.com/matplotlib/matplotlib/pull/15961
- [matplotlib/matplotlib#15961](https://github.com/matplotlib/matplotlib/pull/15961)
- doesn’t need backport becase process doesn’t apply to older versions

### CZI
- Need to start reviewing applicants for RSE (59 applications)

### JOSS review
- https://github.com/openjournals/joss
- needs reviewers, many viz (matplotlib) related submissions

### Job posts on social media + mailing lists

- can core devs (aka Tom) use Matplotlib channels to advertise jobs that are not Matplotlib related?
- yes
- yes, but case-by-case don’t want to turn in to a job board
- no, hold to project related jobs
- consensus: nah

* Policy for advertising jobs on mailing list/discourse/twitter/etc
- matplotlib jobs are always acceptable
- jobs advertised by core devs is case by cases
- jobs advertised by other scipy stack project are acceptable for reciprocity

### security vulnerability disclosure protocol

- have one possible report
- first in very long time
- add to docs: security reporting
- [e-mail]

### matplotlib development friction points
- takes too long to merge a PR
- for new features:
- use experimental/provisional label
- how to alert the user to new features?
- scikit learn maybe has some machinary for opt in
- let stuff break
- large PRs
- backward incompatable
- change internal characteristics
- middle ground for deprecate all the things & some silent fails
- process of maintaining back-compatabiliy is convoluted
- example: make the freetype binding private
- faster release cycle?
- make mpl dev fun again!
- conserative versus adventurism - is mpl set too conservative?
- might be hurting gaining & retaining new contributors
- clearly articulating what actionable steps does the PR need to get in?
- this is hard because conservative versus adventurous?
- maybe different guidelines based on what users are trying to do?
- no data on what parts of the API get hit:
- very used private versus not so used public
- can scrape stackoverflow
- PR ends up getting paralyzed
- what’s the next step,
- who makes the decisions?
- what features should be encouraged
- where is the emphasis in development
- Major library selling points
- stability
- good design
- relability
- on controversional PRs, hard to gauge how much someone really cares
- having named champions for PRs
- named roles are bigger picture leads
- two core devs with strong opposing opinions -
- champion mediates
- middle phase
- enough active people to get opinions on a PR
- nobody feels empowered to push the green button - champion would push it
- Summary
- conservative vs adventorous - gone too conservative
- 3rd party packages
- good example: mpl-finance taken over by finance expert
- bad example: axes grid is unmaintained

#### Takeaways: How to make development fun again
- getting big stuff in is hard
- may break API
- we have become (too) cautious about adding new API
- how to balance velocity vs not making mistakes?
- how to tune this dial?
- how to label stuff as experimental with expectation of near future breakage
- all work is either trivial or impossible / takes years
- named roles / assigned champions on PRs
- we should talk to Andy about how sklearn is this working on
- would faster release cycles help?
- would help with attracting and keeping new contributors
- maybe slim down the existing API

### Meeting notes: move to hackmd?**
- https://hackmd.io/
- [x] make old notes read only
- [x] export 2019 to repo
- [x] consolidate notes and start it on the hackmd