Based on findings in #42 and #43 we define a new structure propositions for the Zalando github organisation.

Proposal will take git flow functionality for pull requests, issues, team structure. Also outline the change in how Zalandos can create new repositories.

Task Headline

The plan for the github migration is complete, this now needs to be shared with the wider tech audience at Zalando so we ensure everyone knows what we intend to do - before we do it...

• We will start migrating all teams from internal names to product names
• Teams will have limited permissions
• Only team members can push to master and approve PRs
• We will enforce PR-based workflows and Codeowner based reviews

There will be cases where teams need help:

• Setting up CODEOWNERS
• Migrating external contributors and team members
• understanding the new workflow with enforced PRs

Tasks

• Write email content on the specific steps we will take
• Send out to all of tech
• Reach out to individual teams to work with them during the migration

Stakeholders

Who do we need to colloborate with to make this happen? - add the deparment to get in touch with

• Tech

For security purposes and for setting an example to the wider world of Open Source, it is important that we enable 2FA for all Zalando organisations on GitHub (except fabric-design).

• Announce program to the Open Source Guild
• Send updated enablement numbers to guild (23.04.18)
• Send updated enablement numbers to guild (26.04.18)
• Email org members with no 2FA (25.04.18)
• Enforce 2FA for all GitHub orgs

• Removing the delta between innersourcing and open source
• Introduce the mindset of open by default
• lower the barrier for participating in open source

Finish the challenge and guiding principles of the strategy document. Add roadmap for Q3 and Q4.

• Review and comment on the new structured document
• Setup meeting with HH (friday)

Create a contributing.md file to define our process and different steps - opening issues, creating PR etc.

Investigate monitoring tools to be able to setup an initial MVP version for OSS monitoring dashboard.

Based on initial research, GhCrawler seems like the best option for collecting GH Data, we must investigate visualisation of the GhCrawler MongoDb data.

Selection criteria

• Open Source / flexible / hackable
• Web based
• Familiar techstack
• Raw Data Access
• Easy to use, deploy and maintain
• Not Real time
• Prebaked visualisations

Tools to investigate

• MeasureOSS - Per
• Grimoire
• Google BigQuery
• GHCrawler + Metabase - Paul
• OSS Tracker - Princiya
• OSS Dashboard - Princiya

Low priority

• Fort George + Metabase
• Gander (broken)

Description

Review the current documentation on how a project is reviewed and accepted into the incubator
Make documents public so there is full transparency on how a project is accepted and what
rules to follow.

Tasks

This is the concreate tasks to complete before the task is marked as done

• Identify and clean up current review docs
• Make public on website
• Retire internal review group repo

Expected delivery

Website documentation on the review process for open source projects at zalando

Currently the stats on the first page only reflect the main Zalando org. These should be updated to include:

• zalando-incubator
• zalando-nakadi
• zalando-stups
• zalando-zmon
• zalandoresearch

Setting up initial team website

• Setup domain name opensource.zalando.net
• Arrange repo
• Website tech setup
• Deploy website to github pages
• Design MVP
• Website content
• Reach out to Corporate Communications
• Reach out to Employer branding
• Setup [email protected]

Description

Collect github members currently maintaining projects on zalando and zalando-incubator
to have a single point of contact when reaching out to maintainers inside zalando.

Tasks

This is the concreate tasks to complete before the task is marked as done

• Collect list of maintainers from repos
• Connect with zalando email (using the maintainers file)

Expected delivery

List of maintainers and a active maintainers email list + addition of all maintainers to the
oss review group

Promote diverse role models to increase participation in Open Source.

• Identify role models
• Promote them together with Employer Branding & Diversity Guild

Description

Move how-to-oss from github repo into ost website and update its content

Tasks

This is the concreate tasks to complete before the task is marked as done

• Refactor content #76
  • Update to fit r.o.p 2.0
  • refine the content
• Enable jekyll on the website #78
• design of content #79
• Archive the how-to-oss repo #72
• Update the review process documentation #71
• Docs template for the website using Jekyll #133

Expected delivery

What is the concrete outcome of this task.

Stakeholders

Who do we need to colloborate with to make this happen? - add the deparment to get in touch with

• Department name

How do we measure the task was completed

How do we measure impact

Initial MVP layout for the monitoring dashboard:

• Layout
• Content
• Tech

Get an overview of the current Github organisations, teams and projects so we know how permissions, people, teams and projects are tied together for our github members.

Understand how this effects git flow in regards to pull requests, issues, comments, reviews and merges.

We need to retain the content at zalando.github.io but make it the project subfolder of the new website. Should be restyled using dress code.

• Understand membership structure #42
• Understand tooling #43
• New Proposed structure #45
• Workshop materials #46
• Write a tech narrative for isssue 66 and 67 #109
• Inform the guild about the changes #66
• Inform tech about the changes #67

The tasks list in the CONTRIBUTING file is indented with extra whitespace.

Depends on #42

Understand how tooling such as Zappr, people.zalando.net and Github Sync depends on the current structure

Determine how much of the current tools can be replaced by native github functionality

• Determine format and frequency
• Lead buy-in
• Study githubs guidelines on open source participation

• determine what format to communicate policy
• find an appealing and nice way of presenting the topic
• discuss if these are made public or not

• Purpose Statement #41
• Tools evaluation #26
• Public reports #28
• Alerts #30
• Dashboard #27
• Validate monitoring data #111
• Setup Metabase #113
• Opensource Roadblock #114
• Collect missing data #115

Identify and get diversity numbers for Zalando's maintainers.

• Reach out to Employer Branding and Diversity Guild for promotions.

Based on the proposal made for #45 training material will be created.

MVP is a slidedeck for use in a classroom setting on the following:

• The Github organisation zalando use
• What you can and cannot do in this structure and why
• Git Flow for teams
  • Submitting Pull Requests
  • Issues
  • Code Reviews
  • Merging

Initial Jekyll setup and deployment on Github Pages.

We need to get analytics from the website page. As mentioned in this issue #60, we will be moving contents from the current zalando.github.io website into this OST repository.

• Check if analytics is already in place from the old repo zalando.github.io
• Write appropriate script for the analytics to work: PR #63

Task Headline

Archive this repository https://github.com/zalando/zalando-howto-open-source because we will refactor the content there and add it on opensource's website.

Tasks

• Archive the repository https://github.com/zalando/zalando-howto-open-source

Stakeholders

Who do we need to colloborate with to make this happen? - add the deparment to get in touch with

• Guild
• Tech (mailing list)

How do we measure the task was completed

How do we measure impact

Description

In order to create a high quality experience for contributors to Zalando open source projects.
We will design a maintainer training program which helps our project maintainers to create and nurture
welcoming and friendly open source projects.

Tasks

This is the concreate tasks to complete before the task is marked as done

• Review process for acceptance into the incubator #71
  • retire oss review group internal repo
• Define the process for graduating from the incubator #73
  • Research how apache and fsf incubators define graduation #74
• Process for maintainers offboarding from Zalando #77
• Maintainer training materials #80

Expected delivery

Training materials for maintainers, offered through the tech academy to all zalando project maintainers

Stakeholders

Who do we need to colloborate with to make this happen? - add the deparment to get in touch with

• OSS Review group
• OSS Guild
• OSS Maintainers

• Figure out how the current github signup flow works (people.zalando.net)
• Design + implement improvements
• Study best practices (microsoft, google and github have samples)
• Communicate the new approach

MVP version to be able to produce reports as part of the community monitoring activity.

Structure and priority of the data for the report
Data sources for the report - lets focus on github

• Reach out to corp comms on report presentation

We need to get in touch with the open source guild to inform them of changes in emails and google group setup.

• https://dependabot.com
• That DCO thing
• Document which bots have been enabled for which orgs

• Purpose of the maintainer training
• risks
• Who will be trained?
• How does this fit in with Incubation - requirement?
• Timeline for implementing
• • Gather Feedback from current maintainers
• • Q4 Initial Version of materials
• • Trial run with small group of maintainers

Define purpose statement to be able to search monitoring tools that best address our purpose.

Points to be addressed:

• What do we want to measure?
• What, how should the monitoring dashboard look like?
• What reports do we want to generate for the community health check?
• What alerts do we need?

To be filled

• Goals
• Jobs
• Team
• Project stats
• Contact (email, twitter)
• Articles (blog, video)
• Link to Zalando orgs
• Show outreach (?) - CNF

Create a PR template to be used with all PR requests.

To be filled

We must discuss the wording and content of Rules of play 2.0 with compliance.

Specifically:

• there should be only 1 recommended license
• by providing a boilerplate project for all projects we can take alot of the complixity out of being compliant
• legal currently have a goal of avoiding commercial use of oss code - which does not work well with the choice of the MIT license
• there is currently 2 set of values / principles around oss, one from the rules of play and one from the guild, we need to decide which one to go with
• Currently in change management rules of play there is a rule that all commits must have an attached specification that explains why the commit was made, how do we ensure that it is not a blocker to adopting open source code while remaining compliant.

We should add a CODEOWNERS file in .github so that we can restrict reviews to members of our team.

Identify existing policy documentation and mark for deprecation, renewal and keeping

• Identify location of docs
• Read through existing policy
• Mark docs to be deprecated
• liaise with the compliance team before publishing

We should add a blog to our website so that we (and invited guests) can contribute. It should be coordinated through Github:

• Jekyll-ify the website #78
• Blog should support:
  • Title
  • Datestamp
  • Tagging / categories
  • Historic article tree
  • Comments
  • Header image
  • Syntax highlighting

Tech setup for building the team website mvp

• Investigate jekyll, hugo, GH pages, Netlify
• Jekyll setup
• Website pages - index.html, css, js files
• Catwatch data
• Travis CI setup
• greenhouse jobs api

Alerting mechanism to monitor community health for OST and maintainers.

• Content
• Tech

• how to communicate to current teams
• how to be involved in onboarding
• Reach out to tech academy

This is to promote and boost maintainer diversity in Open Source.

• Identify programs for participation
• Talk to the Employer Branding team
• Talk to the Diversity Guild

Description

Publish what defines a good open source project and what the process for a project is to graduate
from the incubator.

• what rules needs to be followed
• what is best practices
• what a the key quality indicators we look for
• how long does a project have to reach these goals
• what happens if goals are not met

Tasks

This is the concreate tasks to complete before the task is marked as done

• Write down rules for incubator projects
• Indicators for quality projects on the incubator
• Timeframe for graduation
• What happens if a project does not graduate within timeframe

Expected delivery

Graduation guidelines for the review group published on the ost website

• Agree domains (e.g. opensource.zaland.net, opensource.zalando.com)
• Place request and have the domains pointed to GHP

Task Headline

Communicate organisation changes to the guild and changes to membership permissdsions

Tasks

This is the concreate tasks to complete before the task is marked as done

• Specific tasks to be decided

Expected delivery

Communication plan, materials on new workflow

Stakeholders

Who do we need to colloborate with to make this happen? - add the deparment to get in touch with

• Open source guild