ideas generated during the retrospective at the dev workshop

[Philip Durbin]

I'd like to thank everyone who wrote on sticky notes and discussed them afterwards at the retrospective this afternoon at the dev workshop. A lot of good ideas were generated and I just typed them up so we can reflect on them some more.

Let me back up by saying that our retrospectives are informed by the Principles behind the Agile Manifesto at http://agilemanifesto.org/principles.html which includes, "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly."

The sticky notes we made went under one of three categories: Keep, Start, and Stop. Here are the definitions:

- Keep: What’s going well about how we communicate and work together? 

- Start: What are some things we should try? What are some things that have worked in other communities?

- Stop: What activities aren’t providing benefit? What activities are slowing us down?

Here's what we came up with on sticky notes (edited slightly for clarity) and with a few extra notes from discussing them:

Keep

* Keep having regular community/dev calls. They are useful.

* Keep increasing code coverage.

* Keep the way you develop (Inbox -> Backlog -> Sprint, etc.). This keeps everything moving forward and seems to be effective so far.

* Keep an open roadmap/Waffle.

* Keep adding customization/config options for installations.

* Keep having yearly community meetings.

* Keep adding more automated tests.

Start

* Start posting agendas for community calls. (The last few have been about the community meeting.)

* Start sending community call reminders earlier. Some people only get a digest of the mailing list.

* Start considering alternative times for community calls.

* Start better supporting for external developers contributing code.

* Start closer collaboration with outside developers

* Start small community/IQSS teams based on small deliverables.

* Start letting the community help with items that are higher priority for them.

* Start using a "help wanted" label on GitHub issues.

* Start a Slack channel for the developer community.

* Start supporting a plugin development mechanism.

* Start providing more info on using Sphinx to create documentation.

* Start adding more documentation to the source code (i.e. Javadoc).

* Start having living API docs (e.g. Swagger).

* Start writing more "brain dump" guides like the new Style Guide.

* Start improving the installation process.

* Start adopting a simplified process for documentation changes.

* Start to consider putting documentation and scripts in a separate repo.

* Start making separate pages for developing on Mac vs. Linux vs. Windows.

* Start a community page to have a place for the community to share presentations and other local customizations/documentation.

* Start creating more robust APIs.

* Start moving community meetings to remote exotic (beach!) locations.

* Start thinking about how to capture compute workflows.

* Start adding basic tabular or stats/viz.

* Start creating a dictionary/reference for what people rename different categories. If feasible, integrate it into future versions. If not, keep a record of it somewhere (SQL?) so there can be a record of shifting standards.

Stop

* Stop hard coding text content in source, move to Bundle.properties.

* Stop committing code that decreases the overall code coverage of automated tests.

* Stop using awkward phone-in-only system for community calls.

Thanks again,

Phil

--

Philip Durbin
Software Developer for http://dataverse.org
http://www.iq.harvard.edu/people/philip-durbin