# 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](https://doc.coreboot.org/contributing/gerrit_guidelines.html)
* 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
_______________________________________________
flashrom mailing list -- flashrom@flashrom.org
To unsubscribe send an email to flashrom-le...@flashrom.org
