Date
2021-5-10
...
Time | Who | Item | Notes |
---|---|---|---|
5 min | Jessica Crouch | Welcome 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. | |
Everyone | Team 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 min | Everyone | Closed Pull Requests since April 12, 2021 44 closed | |
10 min | Assignee | Open Pull Requests (is:pr is:open base:master assignee:[name]) | Comments |
Mark Cooper | |||
Alexander Duryee (Unlicensed) | |||
Brian Hoffman | |||
Steve Majewski (Unlicensed) | |||
Dave Mayo (Unlicensed) | |||
Gregory Wiedeman (Unlicensed) | |||
Lora Woodford | |||
5 min | Everyone | Our next meeting is June 14, 2021 at 2pm ET |
...