In-person interviews with actual people, user journey comparison about zappr

[mfellner]

Based on our research, I propose the following shortlist:

• Brand Solutions
• Stups
• Payment
• Tech monkeys (alternatively ACID or Spearheads)
• another non-opensource team EDIT: Order

[prayerslayer]

The "other" team could be Order because I think they have the most experience with Stash.

[hjacobs]

FYI: The AIS team (DI-SCF) migrated to GHE a few weeks ago, so they would be good candidates.

[prayerslayer]

Do you have a contact we can approach directly?

[hjacobs]

Kashif Rasul maybe

[mfellner]

@akauppi has reached out to us and is going to tell us about their workflows in Helsinki.

[prayerslayer]

(Preliminary) summary of interviews and survey

Good

These things people need or like to have:

• Restrictions on PR merge capabilites, e.g. merger not the same as developer, needs n approvals
• Permissions on branches, e.g. who can push, merge PR into etc., possibly separated by branch type (feature, release, master)
• Enforce ticket workflow, e.g. state machine, roles (e.g. spec approver must not be spec writer)
• Enforce task lists
• Enforce ticket-SCM integration, e.g. no PR with in-development ticket
• Enforce CI integration, e.g. min. 2 successful build before merge is possible
• Enforce coding style (hooks?)
• Review tasks that need to be completed, much like here in Github
• Review notifications
• Templates for tickets (custom fields), possibly enforce
• Tree views (in comments, files)
• Proper ticket descriptions
• Emphasize parts of the code for review ("that you really have to look at")

Bad

These things they don't like or want to get rid of:

• Rules of play for OSS a bit unclear
• Insufficient issue descriptions, esp. from people outside the project
• Manual post-merge tasks, e.g. tests
• Long discussions in PRs
• Specification was not correctly implemented
• PRs are no fun: Too big, too complex, context is missing