owned this note   changed 2 years ago  
Linked with GitHub

Planning Meeting: SPECs (including Team Compass Spec)

Date: Monday 11:30 - 12:30 AM
Topics: Specs (including Team Compass Spec)
Issues: #6, #19

Attendees

  • Juanita Gomez
  • Jarrod Millman
  • Matthias Bussonnier
  • Tim H (@betatim)
  • Sanket Verma (@MSanKeys963)
  • Sebastian Berg (@seberg)
  • Inessa Pawson (@inessapawson)
  • Pey Lian Lim (@pllim)
  • Henry Schreiner (@henryiii)
  • Matt Haberland (@mdhaber)

Planning issues

https://github.com/scientific-python/summit-2023/issues/6
https://github.com/scientific-python/summit-2023/issues/19

Ideas from issues

Specs

Brigitta: I've started to open issues in the SPEC repo labeled "SPEC Tools" for bits and pieces that are there to support the adoption of SPECs, implementing these could fall into the "infrastructure" side of this topic at the summit:

https://github.com/scientific-python/specs/labels/SPEC Tools

Team Compass

Tim: Team-compass repos.

Several years ago the JupyterHub team created a team-compass repository. The goal of the repo is to provide a place for "team interaction, syncing, and handling meeting notes across the JupyterHub ecosystem".

The point of this issue is that I think more projects would benefit from having a team-compass. The outcome of working on this would be a SPEC and other material explaining the idea, give advice, etc to popularise the idea.

We use the repo to talk about topics from "reduced availability", over "should we use pre-commit for all repos?", "coordinating outreachy work" and "is self-merging your PRs Ok?". But I think the best way to get a feeling is for people to browse the repo a bit.

Having a place like this creates a place to talk about things that are more about how to work together, than doing the work (which is more appropriate to discuss in the actual project repo).

The structure is popular and since a few years ago most of the other parts of Project Jupyter have adopted them.

It would be interesting to hear what other projects do and find out if there is something worth recommending to the wider community.

Existing SPECs

SPEC 0 — Minimum Supported Versions
SPEC 1 — Lazy Loading of Submodules and Functions
SPEC 2 — API Dispatch
SPEC 3 — Accessibility
SPEC 4 — Nightly Wheels
SPEC 5 — CI Best Practices
SPEC 6 — Keys to the Castle
SPEC 7 — Seeding pseudo-random number generation

Meeting notes

Infrastructure thing for spec – spec repo is now into a new org.

  • One Orgs, vs many Orgs.
  • Matthias: keeping all the docs within one GH org is best.

Spec tool(s):

  • Lazy loader
  • Spec 0 / (old NEP 29)

Think about how we are going to manage those tools.

Where does the backporting bot should live ?

  • Spec is more of an index, and point to an existing tool.
  • Could be good to move/rebrand it.

What is missing to not have the SPECS as draft ?

  • NX/Skimage need to adopt the lazy loader.

During the meeting/ for the meeting:

  • assign roles,
  • SPEC 6, how to share secrets.
  • spin – dev.py generalisation to all projects.
    • Good spec for organisation of a repo ?

There was a bit of discussion around version_info, citation metadata. That could fit a spec (if it’s easy to agree on a large set).

Also quesiton about the release notes.

  • Release notes script
    • skimage script improved in Napari, e.g. ensures labels on all issues
    • Extract changelog entries from PR descriptions
      • GitHub as an option to base the merge commit text from the PR description.

We need a process to send the SPEC from the repo to the projects that will endorse them. What is the process.

  • We have representatives of core projects that have agreed to monitor the SPECs.
  • The process for SPECs is well outlined; but we do need to re-engage projects to ensure that SPECs get endorsed.
  • Projects should use SPECs for broad discussions that affect multiple projects.

Merge release notes tool for NX/Napari and skimage and release it as a separate package.

Identify what action items/initiatives would be a good fit for a decade-long plan for SPP.

Versioning of SPECs?

  • Henry Detecting when SPECs are implemented; could even be set up to generate badges based on URLs. See https://scikit-hep.org/developer/reporeview for example checking developer guidelines best practices, like CI and such.

Some side convo about pet peeve that is deprecation between Sebastian and Stefan.

  • SPEC on deprecation policies, workflows, Hinsen principle, cost on devs vs users, etc.

For the summit

  • Mark SPEC0 and finished. Update all reference to NEP29 to spec 0 in all present projects

    • Write an automatic tool to check repos againt spec0, that projects can use in CI.
    • General the tools to generate the timeline from PyPI.
    • Add SPEC0 badges everywhere.
    • pllim is interested but not an expert.

  • SPEC 1 (lazy loading) out of draft status + pep 690

  • stefan Would like to see:
    • review and acceptance of a few SPECs
    • reviewing the SPEC process to make sure it can still work smoothly
    • identifying outstanding/writing those SPECs

  • SPEC 4 (nightly wheels) + 5 (ci best practices) implement and endorse

    • pllim is interested in collaborating on this one

  • investigate reporeview (https://scikit-hep.org/developer/reporeview)

    • related to SPEC0 above?

  • Spec 3: JuanitaSarah Find out what resources are already there (reaching out to Quansight Labs people)

  • Cautious merging / give time before PRs merged / SPECs endorsed

  • Process for SPEC that is no longer active / relevant?

    • Not yet, but may make sense to add, once that becomes necessary (we've erred on the side of lean process so far).

  • TODO Juanita Add SPECs 6 and 7 to our discussion forum

  • Regular SPEC committee meetings?

    • Wasn't part of the original ask, but would be great to have a more active committee take charge.
Select a repo