Add contracted roles to team page and rename core dev -> core TM (#817)

# Description

As discussed at the previous core **team member** meeting and in other
places, this PR updates our governance docs, core TM guides and About
the Team page to use the title core team member instead of core
developer.

I've also taken this opportunity to list the folks currently in
contracted roles on the team page. I wasn't sure if we wanted to also
list current release manager as that changes more frequently, but happy
to list them as well if folks want!

<!-- Previewing the Documentation Build
When you submit this PR, jobs that preview the documentation will be
kicked off.
By default, they will use the `slimfast` build (`make` target), which is
fast, because
it doesn't build any content from outside the `docs` repository and
doesn't run notebook cells.
You can trigger other builds by commenting on the PR with:

@napari-bot make <target>

where <target> can be:
html : a full build, just like the deployment to napari.org
html-noplot : a full build, but without the gallery examples from
`napari/napari`
docs : only the content from `napari/docs`, with notebook code cells
executed
slimfast : the default, only the content from `napari/docs`, without
code cell execution
slimgallery : `slimfast`, but with the gallery examples from
`napari/napari` built
-->

<!-- Final Checklist
- If images included: I have added [alt
text](https://webaim.org/techniques/alttext/)
If workflow, documentation build or deployment change:
- My PR is the minimum possible work for the desired functionality
- I have commented my code, to let others know what it does
-->

---------

Co-authored-by: Draga Doncila <ddon0001@student.monash.edu>
Co-authored-by: Juan Nunez-Iglesias <jni@fastmail.com>
Co-authored-by: Tim Monko <timmonko@gmail.com>

Author: 4 people

docs/community/governance.md

@@ -44,38 +44,49 @@ can directly help to shape its future.
 
 Contributors are encouraged to read the [contributing guide](napari-contributing).
 
-### Core developers
+### Core team members
 
-Core developers are community members that have demonstrated continued
+```{note}
+We used to refer to core team members as core developers. However, we felt
+that this title did not accurately reflect the broad range of contributions
+we value from our community. We have therefore updated the title to be more
+inclusive.
+
+Some historical artifacts e.g. our google mailing group and our GitHub team
+cannot be renamed. Additionally, NAPs and release notes have not been retroactively
+updated to reflect the new role title.
+```
+
+Core team members are community members that have demonstrated continued
 commitment to the project through ongoing contributions. They
 have shown they can be trusted to maintain napari with care. Becoming a
-core developer allows contributors to merge approved pull requests, cast votes
+core team member allows contributors to merge approved pull requests, cast votes
 for and against merging a pull-request, and be involved in deciding major
 changes to the API, and thereby more easily carry on with their project related
 activities.
 
-Core developers are expected to review code contributions while adhering to the
-[core developer guide](core-dev-guide). New core developers can be nominated
-by any existing core developer, and for details on that process see our core
-developer guide. Core developers can choose to step down from their role and 
-become "emeritus" core developers if they are no longer involved with the project,
+Core team members are expected to review code contributions while adhering to the
+[core team member guide](core-dev-guide). New core team members can be nominated
+by any existing core team member, and for details on that process see our core
+team member guide. Core team members can choose to step down from their role and 
+become "emeritus" core team members if they are no longer involved with the project,
 or feel they do not have sufficient time to dedicate to their role. Emeritus core
-developers can request or be invited to become active core developers at
-a later date and with consensus from currently active core developers. 
+team members can request or be invited to become active core team members at
+a later date and with consensus from currently active core team members. 
 
-For a full list of core developers see our [About the project and team](team) page.
+For a full list of core team members see our [About the project and team](team) page.
 
 ### Steering council
 
-The Steering Council (SC) members are primarily core developers who have additional
+The Steering Council (SC) members are primarily core team members who have additional
 responsibilities to ensure the smooth running of the project. SC members are
 expected to participate in strategic planning, approve changes to the
 governance model, and make decisions about funding granted to the project
 itself. (Funding to community members is theirs to pursue and manage). The
 purpose of the SC is to ensure smooth progress from the big-picture
 perspective. Changes that impact the full project require analysis informed by
 long experience with both the project and the larger ecosystem. When the core
-developer community (including the SC members) fails to reach such a consensus
+team member community (including the SC members) fails to reach such a consensus
 in a reasonable timeframe, the SC is the entity that resolves the issue.
 
 Members of the SC also have the "owner" role within the [napari GitHub organization](https://github.com/napari)
@@ -89,11 +100,11 @@ diversity of voices. All deadlocked votes of the SC will be postponed until
 there is an odd number of members and another vote can be held. A majority of the
 SC will not be employed by the same entity. One seat on the SC is reserved
 for a member elected by the [Institutional and Funding Partner Advisory Council](#institutional-and-funding-partners),
-as detailed below. This member need not be an existing core developer.
+as detailed below. This member need not be an existing core team member.
 
 The SC membership, including the Institutional and Funding Partner (IFP) seat, is revisited every January.
 SC members who do not actively engage with the SC duties are expected to resign. New members for
-vacant spots are added by nomination by a core developer. Nominees should have demonstrated
+vacant spots are added by nomination by a core team member. Nominees should have demonstrated
 long-term, continued commitment to the project and its [mission and values](mission-and-values). A
 nomination will result in discussion that cannot take more than a month and
 then admission to the SC by consensus. During that time deadlocked votes of the SC will
@@ -107,7 +118,7 @@ SC see our [About the project and team](team) page.
 
 The SC is the primary leadership body for napari. No outside institution,
 individual or legal entity has the ability to own or control the project
-other than by participating in napari as contributors, core developers, and
+other than by participating in napari as contributors, core team members, and
 SC members. However, because institutions can be an important source of
 funding and contributions for the project, it is important to formally
 acknowledge institutional participation in the project. We call institutions
@@ -156,36 +167,36 @@ Decisions about the future of the project are made through discussion with all
 members of the community. All non-sensitive project management discussion takes
 place on the [issue tracker](https://github.com/napari/napari/issues) and project
 [zulip](https://napari.zulipchat.com/) community chat channel. Occasionally,
-sensitive discussion may occur on a private core developer mailing list
+sensitive discussion may occur on a private core team member mailing list
 `napari-core-devs@googlegroups.com` or private chat channel.
 
 Decisions should be made in accordance with the [mission and values](mission-and-values)
 of the napari project.
 
 napari uses a “consensus seeking” process for making decisions. The group
-tries to find a resolution that has no open objections among core developers.
-Core developers are expected to distinguish between fundamental objections to a
+tries to find a resolution that has no open objections among core team members.
+Core team members are expected to distinguish between fundamental objections to a
 proposal and minor perceived flaws that they can live with, and not hold up the
 decision-making process for the latter.  If no option can be found without
 objections, the decision is escalated to the SC, which will itself use
 consensus seeking to come to a resolution. In the unlikely event that there is
 still a deadlock, the proposal will move forward if it has the support of a
 simple majority of the SC.
 
-Decisions (in addition to adding core developers and SC membership as above)
+Decisions (in addition to adding core team members and SC membership as above)
 are made according to the following rules:
 
 - **Minor documentation changes**, such as typo fixes, or addition / correction of a
-  sentence, require approval by a core developer *and* no disagreement or requested
-  changes by a core developer on the issue or pull request page (lazy
-  consensus). Core developers are expected to give “reasonable time” to others
+  sentence, require approval by a core team member *and* no disagreement or requested
+  changes by a core team member on the issue or pull request page (lazy
+  consensus). Core team members are expected to give “reasonable time” to others
   to give their opinion on the pull request if they’re not confident others
   would agree.
 
 - **Code changes and major documentation changes** require agreement by *one*
-  core developer *and* no disagreement or requested changes by a core developer
+  core team member *and* no disagreement or requested changes by a core team member
   on the issue or pull-request page (lazy consensus). For all changes of this type,
-  core developers are expected to give “reasonable time” after approval and before
+  core team members are expected to give “reasonable time” after approval and before
   merging for others to weigh in on the pull request in its final state.
 
 - **Changes to the API principles** require a dedicated issue on our
@@ -195,9 +206,9 @@ are made according to the following rules:
 - **Changes to this governance model or our mission, vision, and values**
   require a  dedicated issue on our [issue tracker](https://github.com/napari/napari/issues)
   and follow the decision-making process outlined above,
-  *unless* there is unanimous agreement from core developers on the change in
+  *unless* there is unanimous agreement from core team members on the change in
   which case it can move forward faster.
 
 If an objection is raised on a lazy consensus, the proposer can appeal to the
-community and core developers and the change can be approved or rejected by
+community and core team members and the change can be approved or rejected by
 escalating to the SC.

docs/community/mission_and_values.md

@@ -3,7 +3,7 @@
 
 This document is meant to help guide decisions about the future of `napari`, be it in terms of
 whether to accept new functionality, changes to the styling of the code or graphical user interface (GUI),
-or whether to take on new dependencies, among other things. It serves as a point of reference for [core developers](core-dev-guide) actively working on the project, and an introduction for
+or whether to take on new dependencies, among other things. It serves as a point of reference for [core team members](core-dev-guide) actively working on the project, and an introduction for
 newcomers who want to learn a little more about where the project is going and what the team's
 values are. You can also learn more about how the project is managed by looking at our [governance model](napari-governance).
 
@@ -43,7 +43,7 @@ napari aims to be the **multi-dimensional image viewer for Python** and to **pro
 (our-values)=
 ## Our values
 
-- We are **inclusive**. We welcome and mentor newcomers who are making their first contribution and strive to grow our most dedicated contributors into [core developers](core-dev-guide). We have a [Code of Conduct](napari-coc) to make napari
+- We are **inclusive**. We welcome and mentor newcomers who are making their first contribution and strive to grow our most dedicated contributors into [core team members](core-dev-guide). We have a [Code of Conduct](napari-coc) to make napari
 a welcoming place for all.
 
 - We are **community-driven**. We respond to feature requests and proposals on our [issue tracker](https://github.com/napari/napari/issues), making decisions that are driven by our users’ requirements, not by the whims of the core team.
@@ -58,7 +58,7 @@ a welcoming place for all.
 
 - We value **simple, readable implementations**. Readable code that is easy to understand, for newcomers and maintainers alike, makes it easier to contribute new code as well as prevent bugs.
 
-- We value **education and documentation**. All functions should have docstrings, preferably with examples, and major functionality should be explained in our [tutorials](https://napari.org/tutorials). Core developers can take an active role in finishing documentation examples.
+- We value **education and documentation**. All functions should have docstrings, preferably with examples, and major functionality should be explained in our [tutorials](https://napari.org/tutorials). Core team members can take an active role in finishing documentation examples.
 
 - We **minimize [magic](https://en.wikipedia.org/wiki/Magic_(programming))** and always provide a way for users to opt out of magical behaviour and guessing by providing explicit ways to control functionality. We support NumPy array like objects and we prefer to educate users rather than make decisions on their behalf. This does not preclude the use of sensible defaults.
 

docs/community/team.md

@@ -1,8 +1,8 @@
 # About the project and team
 
-napari is a consensus-based community project. Anyone with an interest in the project can join the community, contribute to the project design, and participate in the decision making process. You can learn more about how the project is run by reading our [governance model](napari-governance). This page lists our current and emeritus [core developers](governance.md#core-developers). Core developers are community members that have demonstrated a sustained commitment to the project through ongoing contributions and that they can maintain napari with care.
+napari is a consensus-based community project. Anyone with an interest in the project can join the community, contribute to the project design, and participate in the decision making process. You can learn more about how the project is run by reading our [governance model](napari-governance). This page lists our current and emeritus [core team members](governance.md#core-team-members). Core team members are community members that have demonstrated a sustained commitment to the project through ongoing contributions and that they can maintain napari with care. We also list our current and emeritus steering council members. Finally, the project currently has a number of paid team members in various roles supported by grants. They are listed below under the [Team Roles](#team-roles) section 
 
-## Current Core Developers
+## Current Core Team Members
 
 - [Ashley Anderson](https://github.com/napari/napari/commits?author=aganders3) - [@aganders3](https://github.com/aganders3)
 - [Draga Doncila Pop](https://github.com/napari/napari/commits?author=DragaDoncila) - [@DragaDoncila](https://github.com/DragaDoncila)
@@ -20,7 +20,7 @@ napari is a consensus-based community project. Anyone with an interest in the pr
 - [Carol Willing](https://github.com/napari/napari/commits?author=willingc) - [@willingc](https://github.com/willingc)
 
 
-## Emeritus Core Developers
+## Emeritus Core Team Members
 
 - [Ahmet Can Solak](https://github.com/napari/napari/commits?author=AhmetCanSolak) - [@AhmetCanSolak](https://github.com/AhmetCanSolak)
 - [Alister Burt](https://github.com/napari/napari/commits?author=alisterburt) - [@alisterburt](https://github.com/alisterburt)
@@ -46,6 +46,21 @@ napari is a consensus-based community project. Anyone with an interest in the pr
 - [Nicholas Sofroniew](https://github.com/napari/napari/commits?author=sofroniewn) - [@sofroniewn](https://github.com/sofroniewn)
 - [Talley Lambert](https://github.com/napari/napari/commits?author=tlambert03) - [@tlambert03](https://github.com/tlambert03)
 
+# Team Roles
+
+To best serve napari's development, operations, and community, several team roles are contracted. Currently contracted roles are listed below:
+
+- Developers-in-Residence: Grezgorz Bokota, Lorenzo Gaifas, Draga Doncila Pop
+- Community Managers: Tim Monko, Lorenzo Gaifas
+- Operations Manager: Draga Doncila Pop
+- Release Manager: Rotating role. For current release manager see the Zulip [#release](https://napari.zulipchat.com/#narrow/channel/215289-release) channel.
+
+We are also contracting with [Quansight](https://quansight.com/) for some key maintenance items:
+
+- [Melissa Weber Mendonça](https://github.com/melissawm) is working on auto-generating videos and screenshots for our documentation and other documentation maintenance & improvements
+- [Jaime Rodríguez-Guerra](https://github.com/jaimergp) is working on maintaining and improving our bundled application and the `napari-plugin-manager`
+- [Daniel Althviz Moré](https://github.com/dalthviz) is working on refactoring our layer controls implementation, improving the `napari-plugin-manager`, and migrating our application model to `app-model`
+
 ## Project history
 
 The napari project began in the spring of 2018. It was born out of the shared need for fast n-dimensional image viewing in Python by project co-founders Loïc Royer, from the Chan Zuckerberg Biohub (CZ Biohub), and Juan Nunez-Iglesias, from Monash University. Since then it has grown rapidly to now also provide a graphical user interface to a plugin ecosystem of image analysis tools for scientists to use in their daily work.
@@ -56,7 +71,7 @@ Early development on the project was led by Kira Evans, first as an intern with
 
 You can read a full history of the project’s founding and early development in this [blog post](https://ilovesymposia.com/2019/10/24/introducing-napari-a-fast-n-dimensional-image-viewer-in-python/) from Juan.
 
-Over time, napari has grown to over 80 direct contributors. Talley Lambert, from Harvard Medical School, began contributing around the time of Juan's blog post, and has been a critical driver of napari's development ever since. We have core developers located in three continents and three biweekly community calls spread across the day to try to accommodate users and contributors in any time zone.
+Over time, napari has grown to over 80 direct contributors. Talley Lambert, from Harvard Medical School, began contributing around the time of Juan's blog post, and has been a critical driver of napari's development ever since. We have core team members located in three continents and three biweekly community calls spread across the day to try to accommodate users and contributors in any time zone.
 
 Read more about napari’s [mission and values](https://napari.org/stable/community/mission_and_values.html), how to get started as a [contributor](https://napari.org/stable/developers/contributing.html) or join us in our [zulip chat](https://napari.zulipchat.com/login/) for a more synchronous conversation. You can also follow us on [mastodon](https://fosstodon.org/@napari).
 

docs/community/working_groups.md

@@ -7,7 +7,7 @@ Working groups are subteams of the napari community formed by members interested
 We believe working groups are a helpful way to move forward work on particular topics. The following guidelines serve to help community members form and/or maintain healthy working groups. Working groups should:
 
 - Identify at least two co-leads responsible for the creation and continuation of the group.
-- Have a [core developer](https://napari.org/community/team.html#current-core-developers) “sponsor” who is kept aware of work and can help shepherd through PRs as needed. If you don't have a sponsor in mind directly for your proposed working group, please post on the `#general` channel on [Zulip](https://napari.zulipchat.com) and ask whether any core members would like to sponsor your group.
+- Have a [core team member](https://napari.org/community/team.html#current-core-developers) “sponsor” who is kept aware of work and can help shepherd through PRs as needed. If you don't have a sponsor in mind directly for your proposed working group, please post on the `#general` channel on [Zulip](https://napari.zulipchat.com) and ask whether any core members would like to sponsor your group.
 - Create a readme for your [working groups folder](https://github.com/napari/meeting-notes/tree/main/2021/working-groups) that names leads/sponsor, describes the working group’s core goals/priorities, lists Zulip channel, and links to meeting schedule (see readme template below).
 - Identify achievable goals and deliverables that map thoughtfully to napari’s larger strategies and [roadmap](https://napari.org/roadmaps/index.html). These goals may focus on specific short-term goals or longer term efforts that still require exploration.
 - Hold regular public meetings that are listed on the [napari community calendar](https://napari.org/stable/community/meeting_schedule.html). Cadence is up to the team, but monthly minimum is recommended.
@@ -41,7 +41,7 @@ This folder contains meeting notes for the **working group name**
 
 **(Co)leads:**
 
-**Core developer sponsor:**
+**Core team member sponsor:**
 
 **Link to Zulip channel**