Project governance

Problems

• Decision making process (who votes, how we count votes?)
• Hierachy between groups (is dev is the top management group?)
• No Arch Game Rules / RFC / PEP (we have no written rules and process to update them, like TU bylaws) Review process: leadership?

Bus factor

• lower bus factor by actively encouraging single-person projects to find co-maintainers

Project intransparency

• share / publish / highlight SPI report

Developer intransparency

• open up developer role
• encourage developers to (be able to) work on all internal projects

Dealing with finances

• money spending is dealt with via Aaron + developer consent (which can take long)
• think about codified “allowance” for yearly events (e.g. Arch Conf) where community members get travel refunds
• delegation of spending, e.g. any developer can spend up to $500 without approval (e.g. a dinner); 3 developers required for up to $5000; all + Aaron required for more?
• allowing for e.g. infrastructure team to spend
• get Hetzner to bill SPI instead of Ionuţ (aka wonder)

Project management

• encourage (and do!) online meetings, pair programming
• be mindful to opt out properly (not silently), if there’s no time

Team

• do (community centric) Arch Conf yearly!
• meet at FOSDEM (hackathon!)
• create a Conf, that is more user centric (requires sponsors)

Call for sponsors and proposals

• page on wiki/news website
• twitter annoucement
• we’re not really in need of sponsors for money, are we? sponsors make it possible to pay for accomodation also becomes necessary if we open things up to users. I think we can get full reimbursement for all team members with our current situation, but getting other people to join will need sponsors. We don’t really have the business connection that would get companies to send their employees to our conferences. Foxboron: The donations can’t keep up reimbursments for multiple events a year, even just once a year will take a hit if this is only internal. The monthly avg donations amount to around 200-400 USD in total. - https://spi-inc.org/treasurer/

Arch Linux Project Leadership

• Identify technical problems in Arch (esp. not social/behavioral problems)
• Conduct regular meetings in which to discuss problems and find resolutions to those (assign to subleaders, defer, close)
• Organize a list of ongoing processes/subprojects and keep track of those (regularly poll people involved)
• Leadership must have supreme decision making powers over technical domains (I think we should not give techincal decisions to a leadership/management role). How decisions are done should be defined in a decision process, which detail the way decisions have to be taken (majority, unanimity, condorcet) and by who (the dev, the tus, the whole statff, the team, the leader).

Leadership for subprojects

• Appointed by project leadership during meetings to tackle a specific technical problem
• Identify issues and tasks in a specific technical domain
• Conduct regular meetings in which project specifics are discussed, progress is documented and shared with everyone afterwards
• Track progress on the subproject’s tasks

Ideas

• https://pad.sleepmap.de/p/2019-arch-conf-project-governance-idea-1
• https://pad.sleepmap.de/p/2019-arch-conf-project-governance-idea-seblu (technical council project leadership)
• $YOUR_IDEA_HERE

Actionables

• Decide whether to have leadership be a group or a single person
• Decide whether to have a regular leadership rotation (with a pre-defined term) or defining criteria to remove a leader
• Talk to Aaron about this and get his sentiment (direct email)
• Explain to entire project why this is required and what we’re planning to do (mailing list mail to arch-dev)
• Find people willing to take leadership roles
• Plan a follow up meeting