# 7th April 2022, 6:00 - 7:00 am UTC+0
Attendees: Martin, Michal, Felix, Anastasia, Nikolai, David, Thomas, Nico, Arthur, Edward
## Decisions Summary
* Write a script to email out a summary every weekend. Martin can work on a script. * Gerrit guidelines document. Anastasia will start something. * Start using the redmine bug tracker. There are still issues with it, but we’re going to start using it in its current state and work on it as we go. Felix will work on this.
## Agenda
* [FelixS] Hackathons need a reboot. So I’m thinking about doing one. Please share :) * [Poll and some more details](https://terminplaner4.dfn.de/pBooK8FBDlM2zDwa) * Darmstadt, Germany. 10. - 12 June * [Edward] Not every developer has the resources to spend their whole time in IRC and have a spiritual connection with a select few. * How to ensure each code review pass results in a contributor that knows where they stand? - what's next, what's done, when things are going to be merged. * How to avoid walking on eggshells and guessing how to avoid arguments on every contribution but at the same time make tangible progress? * Looks like this topic is closely related to the next one, let's discuss them together? (All notes are done below). * [Edward] How to avoid constant politics in every contribution and instead find a path to allow contributors to not feel ostracized for daring to make a change even when the change may not be useful to others in the immediate sense. * Nikolai: hard to understand whether people are looking at the change, do they have thoughts. Hard to get to know the current status of patch? How to coordinate things? There are many channels? * Nikolai: hard to know whether it is ok. If there is no response, does it mean everything is okay, or no one had a look? * Edward: If people send patches, they need to know what the next step is? * David: gerrit plugin which pings reviewers every 48h ? we need some automation * Edward: observation. Both sides expecting action, or both sides are not sure whose turn? If something is +2 , can it be merged? How to understand that something is ready to merge? * Nikolai: how to ensure there is a consensus? People who are unfamiliar with the process don’t know how to proceed and then give up. * Silicon vendors are unfamiliar with the process. Can they officially support new chips? They attempt to send a patch, and then they are confused on what are next steps. Sometimes good ideas come up in code reviews, and it is not clear who should do that. * David: If adding a new chip requires some refactoring, maybe someone can take that work and do a refactoring? * Edward: We can create a bug in this situation, and prioritize the bug, so that refactor idea is not dropped. * Martin: We need guidelines, maybe “gerrit guidelines”. Coreboot has [https://doc.coreboot.org/contributing/gerrit_guidelines.html%5D(https://doc....) * Review comments should make clear what is next step * [Edward] How to make the project more accommodating to silicon partners so we can start getting direct support from manufacturers? * Often non-native speakers, * Often not well practiced in free software workflows, * Often need help and guidance to bring them into the fold. * [Edward] How to avoid commits sitting around for years in some weird state between reviewed and unmerged. * Improve project velocity while maintaining stability (improved testing, capture mistakes in tests) * Nico: Can we cherry-pick from coreboot guidelines? Only the bits that apply? * Nico: we can say “write to the mailing list if you don’t know what to do and patch needs attention” * Felix: Can we share the same guidelines as coreboot? We share processes and concepts * Edward: Let's start with our own. Copy-paste and cherry pick model. * Edward: at the end of week an email with the list “everything that has +2”. Martin: We can write it in bash. * [David] We have a GSOC student who wants to do some of the easy projects. Are those projects supposed to be saved for new contributors to have something easy to do? * [Anastasia] The easy projects page needs to be updated, but the projects do need to be done. Since they haven’t been done in 5 years, let’s let the students do them. * [Felix] Employees at companies aren’t interested in doing the easy projects. * [Edward] Let’s adopt the bug tracker and mark bugs as “easy” for people to work on. * [Anastasia] Students should do a single easy project, then move on to a single full project. * [Edward] How to get the mailing list into a usable medium and the code review tools into being for code review only. Move noise to a bug tracker. * Capture ideas in bug tracker. Ideas come up in code reviews, good ideas that need to be done “in a separate patch” and then this is lost. * Felix: some issues left to be configured in the redmine instance. * Nico: we can start using bug tracker with email feature disabled, and then see how it goes. Setup email feature can be the first ticket? * Let’s start using it? * [Edward] How to move to a culture of searched responsibility over constant finger pointing? * Some kind of policy for breakage. * Understanding that software breaks, it is impossible to catch everything in review. * Culture around writing tests and documentation. * Edward: revert policy? Anastasia: There is a thread on mailing list, revert policy is one of the topics