Skip to content

Latest commit

 

History

History
78 lines (70 loc) · 4.58 KB

2020-06-09.md

File metadata and controls

78 lines (70 loc) · 4.58 KB

ISIS TC Meeting June 9, 2020 @12PM MST

Attending

  • Jesse Mapel
  • Ross Beyer
  • Kris Becker
  • Victor Silva
  • Andrew Annex
  • Stuart Robbins
  • Audrie Fennema
  • Kristin Berry

Agenda / Notes

  • Action Items from last meeting
    • Add landing at .gov website, can redirect to github. Jesse will ensure this gets assigned and scheduled (ASC)
    • Come up with a way for people to apply to the TC (Jesse)
    • Generate a rough Authors list (Andrew)
    • Look at issue #94 and #95 (all)

Notes

  • Application to planetary software is continuing
  • The redirect on the landing page is going to happen this week
  • Contributors list is PRed in a done
  • Contributing guidelines are still not updated. We need a mechanism to keep these up to date
  • AAnnex can add a PR that updates the PR template
  • JMapel can add to the release docs to have the authors list can be updated
  • JLaura can check with zenodo to see about getting the authors file updated correctly when we do a release. He will determine what needs to be done manually and can then update the release procedure docs.
    • Zenodo linting is sad
    • Ross knows about the things
    • This is going to be manual :(
    • Down the line, automated on PR, this would be nice to have. Also good for continuous release (the ultimate goal).
    • Automation of the authors file isn’t too bad; need to handle duplicate authors using different handles/e-mails
  • Author ordering
    • Probably not alphabetical
    • Project lead, alphabetical contributors
    • Be explicit in the authors.rst that the first name is likely not the person doing all the good work
  • Lifecycle of issues
    • We do not have a policy document at this point. Having a policy document would be a nice thing to have
    • Someone open a PR with the policy document describing the life cycle
    • We do not need to be prescriptive of the process, we need a set of guidelines on what/when/how things are pruned
    • Options:
      • Reachout to the original poster and ask about the current need
      • Close with a note and then ask the poster to reopen if this is still an issue (enhancements)
      • How do we handle bugs?
        • Other communities are +1 on issues that are of interest. We don’t see this.
        • A date based flush point is an option
        • A person trying to replicate and then pinging back is an option
      • What are the goals?
        • Promote participation
      • Moving forward:
        • Leave bugs
        • Go with a date based policy
        • Is this a one time thing?
        • Newer issues are perceived to have higher value by the developers
        • This isn’t specifically a count issue; this is a resource constraint issue
        • We need to engage the users better on enhancement requests to help them define the relative value of the enhancement request. This is a going forward thing.
        • JLaura will open a PR on the ISIS3 repo with a draft policy / discussion and then go from there
        • JLaura, next retro discuss the LTS model and release velocity; RBeyer will open an issue on the TC repo to get this discussed
        • JLaura will PR in the meeting notes

Discussions for next meeting

  • Long term support, release velocity
  • Issue lifecycle

Action Items

- JLaura will open a PR on the ISIS3 repo with a draft policy / discussion and then go from there
- JLaura, next retro discuss the LTS model and release velocity; RBeyer will open an issue on the TC repo to get this discussed
- JLaura will PR in the meeting notes
- AAnnex can add a PR that updates the PR template
- JMapel can add to the release docs to have the authors list can be updated
- JLaura can check with zenodo to see about getting the authors file updated correctly when we do a release. He will determine what needs to be done manually and can then update the release procedure docs.

Next Meeting

  • July 14th @ 12pm MST