Tools Evaluation

Owned by Bill Branan
Jun 16, 2017
5 min read

Tools to support collaboration - November 2013 tool evaluation and selection

A small subgroup has been appointed to identify candidate tools to help the project team manage communication and facilitate collaboration. This subgroup will identify candidates and a process for all team members to test and provide feedback, with a goal of making final selections by December 4, 2013:

  • November 25 - December 2, 2013: identify candidate tools and criteria
  • December 2 - 6, 2013: tool testing/demos
  • December 4 6, 2013: votes and feedback due

Synchronous communication - live voice/video conversations, screen sharing, text chat. Used for daily standup, biweekly demos/sprint planning sessions, and any ad hoc or other team meetings.

  • Desirable features/criteria
    • High: stable, low latency
    • High: scalable, able to support simultaneous connections from 10-20+ participants
    • High: good support for voice participationĀ 
    • High: screen sharing support and stability across common browsers and OS'es
    • Medium: should have persistent/stable URL direct to team collab space/room
    • Medium: supports voice participation via computer or phone
    • Medium: no cost or partner willing to cover fees for whole project
    • Medium: support for recording so that sessions can be captured for later viewing
    • Medium: relatively painless method for account provisioning, adding users to sessions, etc.
    • Low: presenter can mute participant audio/video selectively or en masse
    • Low: support for camera video (peopleface video, not screen-sharing, which is of higher priority)
    • Low: real-time file sharing through system
    • Low: drawing or annotation tools
  • Candidate systems
    • Skype
      • Are there reliable, free solutions for multiparty conversations?Ā  (FreeConferenceCallHD.com has been problematic --Ray)
      • To answer my own question: Voice-only calling for groups is pretty straightforward and apparently can have up to 25 participants. --Ray
    • Adobe Connect
    • Google+ Hangouts
    • join.me
      • Free version limited to 10 participantsĀ 
      • (DCE has a pro account that we'd be happy to use for a test if you'd like, we'd also be happy to spring for a 1-year project hydra account - our results are similar with most other technologies: highly dependent on the end-point network connection, but we've had good luck calling into their conference numbers over mobile, landline, and speakerphone - Mark)
  • How to test and provide feedback (coming soon)
  • PREFERENCES
    • Ray - Google+ Hangouts
    • Jeremy - Google+ Hangouts
    • Mark - Any tool for screensharing/broadcasting/recording, always set up a dial-in bridge for large group meetings, any tool for ad-hoc small group get together (hangout, IRC, Skype)
    • Claire - Adobe Connect for large group, Google+ Hangout for smaller/ad-hoc. 10 person limit on Google+ means it will not work for large group.

Story and task management

  • Desirable features/criteria
    • Critical: integration with github pull requests/merges (i.e. state change can be managed via commit messages) (Jeremy: not sure I agree that this needs to be weighted this highly. It is possible to separate story and task management from code management. May be a point for some further discussion. -Claire; Claire: I would like to have a conversation about this, can you add me to the tooling discussion meeting? For reference the criticality of this feature is so that we can automate notifications regarding Finishing and Delivering of Stories. I have already been asked what features are being deployed, and the only real answer is in the code; Without that connection my answer will be much more time consuming to construct and will be very error prone. This is especially complicated as some features are Finished but are dependent on other features before they can all be Delivered. Also for consideration, is that each institution may have installations at different versions and will want to determine what changes have been made; Connecting commits to stories will help for deep dive and high level understanding.)
    • High: differentiates between stories and tasks
    • High: support for sprints, backlog
    • MediumHigh: direct integration with github issues (Jeremy: direct integration is of higher importance than drag-and-drop and story point support)
    • High: ranking within backlog (or multiple backlogs)
    • Medium: RubyMine integration (available for both JIRA and PivotalTracker ā€“Ray)
    • Medium: story point support
    • Medium: drag-and-drop support for moving tasks and stories
    • Medium: no cost or partner willing to cover fees for whole project
    • Low: support for epics, labels, filters, or some other method of grouping/organizing tasks beyond stories and tasks
  • Candidates
    • HuBoard + github
      • Given that PivotalTracker is free for Open Source Projects, this has a paltry subset of features compared to Pivotal Tracker
    • JIRA Agile (formerly GreenHopper) + JIRAĀ 
      • Duraspace JIRA integration with Github is not "immediately obvious" to me
      • JIRA integration with Github in ND's install was non-trivial
    • PivotalTracker
      • Used by Fedora Futures (instead of JIRA)
      • Github integration with PivotalTracker by default posts an update to each story with a git commits tagged with the Pivotal Tracker issue number.
      • PivotalTracker provides a gem that allows even greater access to the PivotalTracker issue. One example use of the gem provides a script for transitioning Finished stories to Delivered stories upon deployment to a staging environment. By automating this behavior developers don't need to manage the "which of the finished stories were deployed" headache.Ā http://pivotallabs.com/level-up-your-development-workflow-with-github-pivotal-tracker/
      • Command line tools to help planning, stories being worked on, etc. (http://jtushman.github.io/blog/2013/08/15/introducing-pivotal-tools/) (Jeremy: As a developer and tech lead the command line tools are fantastic for keeping the tasks close to where I'm doing the work)
      • Excellent UI for searching and labels; Keeps the project context and adds a new result column to the board
  • How to test and provide feedback (coming soon)
  • PREFERENCES
    • Jeremy - PivotalTracker; The developer-facing tooling support for PivotalTracker is extremelyĀ valuable to me adding lots of assistance for both a developer and scrum master.
    • Ray - JIRA
    • Mark - Story and Backlog management inĀ JIRA, development task and bug management in github
    • Claire - JIRA
    • Randall F. (Indiana) - We have lots of experience at IU with JIRA/GreenHopper/Rapid Boards; concerned with Pivotal Tracker not being able to model stories/sub-tasks. The scrum tutorial today (12/9/13) seemed to suggest that epic/story/sub-task would be practice, which doesn't seem to line up to Tracker.

Documentation/notes

  • Desirable features/criteria
    • High: some support for WYSIWYG
    • High: consistency with other Project Hydra Documentation from both an administrative and discovery standpoint
    • Low: direct integration with github (question)
  • Candidates
  • How to test and provide feedback (coming soon)
  • PREFERENCES
    • Ray - Confluence on DuraSpace
    • Jeremy - Tech docs in Github; Google+ is a communication channel for temporal communications (i.e. Scrum Notes, Releases announcements that point to a Wiki, etc)
    • Claire - Confluence on DuraSpace wiki. (Github in general is very challenging for non-developers.) Updated 12/9/2013: +1 to what Mark says below.
    • Mark - Confluence for project, planning, scheduling documentation, Github wiki for installation, configuration, feature capability documentation

Code management and versioning (is it even worth identifying candidates other than github?)

  • Desirable features/criteria
    • It should be github
    • because that's what Hydra uses
    • the end
  • Candidates
  • How to test and provide feedback
  • PREFERENCES
    • Jeremy - GitHub
    • Ray - GitHub
    • Mark - github
    • Claire - GitHub

Asynchronous (email) communication - listserv-type email interactions (or have we already settled on the googlegroup?)

  • Desirable features/criteria
    • High: no cost or partner willing to cover fees for whole project
    • High: email archiving and/or web forum view
    • Medium: shared list administration
  • Candidates
  • How to test and provide feedback
  • PREFERENCES
    • Ray - Google group
    • Mark - google group
    • Claire - Google Group

Other

  • Shared calendar
  • Wireframing tool(s)
    • Note: The DuraSpace JIRA includes integrated support for creating wireframes ā€“Ray
  • Is IRC a separate category? Will it replace or be replaced by something above?

Ā