2017-11-07 Meeting notes

Tech Docs Workplan for 2017-2018

• Pretty sparse–currently the documentation is more about setting up servers generally, but not written with ArchivesSpace in mind particularly.
• Possibility of having different instructions based on environment.
• People want more information on SSL config.
• Solr example from Bobbi (I think?)–they can be Guinea pig. The Tech Docs Workplan will be updated.
• This is a good place to start, especially with people who have experience configuring their own stuff. No particular boundaries, e.g., about Windows–"document the mess out of everything."

2. Enhance plugin documentation

• Harvard custom version of the PUI as a plug-in–want it to be as minimal as possible. Running into all kinds of interesting scenarios–lot of questions at this point.
• Updating plug-ins to work from 1.5 to 2.0. Would involve taking issues/questions and updating this page in the documentation to better serve needs.
• Helping people who are getting started with plug-ins as audience.
• Mainly plug-in development–any installation specifics go more with individual plug-in documentation not generic plug-in documentation.

3. Make it easier to contribute to tech docs

• Last instance of this group thought it would be beneficial to make it easier/clearer for community to contribute to tech docs.
• One way to facilitate would be to move existing tech docs from inside ArchivesSpace repo to its own.
• Move READMEs to separate repo to start. Might help people who feel uneasy about contributing to core repo.
• Usability, too.
• How much more work would this be for developers? Might actually help developers remember to add to the documentation. One of the issues is that they are just spread out everywhere now. This alone is intimidating.
• Having this organized will help with reviewing top to bottom.
• This is the foundation piece.
• Other barriers? E.g., corresponding with ArchivesSpace release cycle. Laney: as a minor release. The process that builds the statics site–would this need to change? Yes. Is this a big or small change?
• A lot of this depends on how we organize it. Organization: Main README at the root would be a TOC. Would probably be easier to work with in sub-directories. Top would get messy otherwise.
• Look at what's there and see what makes sense. Directories could resemble current BUILT static site (not the original places these are coming from).
• Current organization is problematic. Maybe can give this some thought.
• Have someone take a first stab–easier to think through it if one person does it. Hard to do as a group.
• Heads-down developers are actually the least able to approach this the way a newbie would.