Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Date

2021-5-10

...

TimeWhoItemNotes
5 minJessica CrouchWelcome and Announcements
5 min 

Old Business


Everyone

Developer Onboarding wiki pages for review and enhancement - /wiki/spaces/ADC/pages/894533891

Notes from last meeting:

Should Core Committers be responsible for the Resource for Developers section of the tech-docs, scavenge what is useful from the developer on-boarding resources and sunset the rest?

Some of it (especially what needs to be current with the latest release) should go to tech docs. Background info should stay and be marked as historical or unmaintained. 

This team should mark the pages they want moved to tech docs.  Once they're in tech docs, Core Committers is interested in their accuracy and maintenance but wouldn't want to be primarily responsible for them. 

Once tech docs is onboard, link to tech docs and say that they have moved to to tech docs. Mark is going to bring this up at the next tech-docs meetingThe tech docs sub-team is open to merging the necessary docs.  This team will spend 20 minutes each meeting going through the wiki pages and doing a quick assessment to determine if the page should be moved to tech-docs, kept on the wiki for historical purposes or trashed.  

For those that should be merged, they'll be assigned to a core committer to merge to tech docs

Dave Mayo (Unlicensed)Anything from the Ad Hoc API group? Any forthcoming PRs?

Lots of things being updated and making forward movement. 

30 min

New Business/Open Discussion


Lora/Brian/Mark

3.0 update

https://github.com/archivesspace/archivesspace/releases/

Brian gave an overview of the issues that arose during the release process.  The group discussed some of the larger issues related to various dependencies and issues related to how the software is built/packaged.  Going forward, this group may deliberate some larger development policies and procedures when the developers want some advisement. 

EveryoneTeam project: Pull request / commit history policy and documentation

This is a worthwhile project that the team will back burner until after the development docs review. There may be some content to poach from that. 

It is worth identifying how much of what we need from people submitting PRs can be automated (review of the check boxes/requirements at the bottom of the form) and if/how to apply GitHub branch rules.


Everyone

Core Committers Mission/Community Engagement

One primary action item from the last meeting was the team's desire/need to move away from the current role of the group as primarily reviewing PRs to play a more active role in fostering a community of developers in ArchivesSpace. We discussed the possibility of hosting quarterly calls similar to the “office hours” the training corps is testing. These calls would include as many of the Core Committers as possible with a theme or topic for the call that would require about 10-15 minutes of “presentation” from a team member and then we’d take questions from a feedback form and on the fly. Hopefully community discussion will spring up naturally. I mocked up a working doc for us to keep the ball rolling on this discussion between meetings. I already put lots of my own thoughts on the doc, please do the same. You can find that at https://docs.google.com/document/d/168Je7iVUb2QspI_EdKpCCiQR-jO2vqcwA8RRwIcXwfw/edit?usp=sharing.


Notes from last month:

Pre-Covid/when Laney was on board the team felt more purposeful.  The group has felt adrift. 

This group may not be the best to address reviewing PR. The group is a lot and another commitment.  Is there value in that?

The conversations are valuable and great connections are being made.  Is there a way to increase those valuable conversations. 

There is a desire to have a better idea about the background and design of the application.

A larger discussion about how decisions are made in lots of different ways and places was had. Core Committers doesn't understand where information comes from or how decisions.  This group feels like it is operating in a vacuum/in the dark. 

This group could be the group to form a developer community.  How do we do that without giving an individual invite to people but make them feel empowered on their own? Could this group offer more mentorship/engagement.

The idea of an office hour or quarterly call for this group like the trainers came up. 

Merging PRs was important for the team to accomplish when there was one paid developer for ArchivesSpace.  Now there is less urgency and need for help with that. Some felt reviewing PR was personally valuable to if it isn't a value to ArchivesSpace, it may not be valuable anymore. Though there may be projects or short term need for someone to take point as reviewerThe team affirmed this is something they want to do. 

Mark suggested offering a very broad conversation topic for the first call like "Bring any question you've ever had about ArchivesSpace development."

Please review the google doc linked <<< and make comments and suggestions before the next meeting on June 14. If the team makes some movement on the docs, then Jessica will send out doodle polls to get the ball rolling on this series.

3 minEveryone

Closed Pull Requests since April 12, 2021
(is:pr is:closed base:master merged:>2021-4-12)

44 closed


10 minAssignee

Open Pull Requests (is:pr is:open base:master assignee:[name])

Link to open pull requests: https://github.com/archivesspace/archivesspace/pulls


Comments

Mark Cooper


Alexander Duryee (Unlicensed)


Brian Hoffman


Steve Majewski (Unlicensed)


Dave Mayo (Unlicensed)


Gregory Wiedeman (Unlicensed)


Lora Woodford

5 minEveryoneOur next meeting is June 14, 2021 at 2pm ET

...