Atomozero echoed similar caution from a more practical angle, questioning whether it makes sense to set up enforcement structures before there's even a codebase, and pointed to other projects where this went poorly. The suggestion there was to start with something minimal and grow it only if actually needed.
I agree, for Code of Conduct we can start with a few bullet points and grow into something more formal later. It's good to have some definition from beginning, but don't need to be overburdened with process.
Atomozero Fork model: a clean break, or staying in sync with upstream Haiku releases?
Clean break, but review Haiku commits periodically - especially while the codebases are pretty similar.
Atomozero Scope of BeOS/gcc2 and Haiku app compatibility
No to BeOS/gcc2, yes to 32bit with modern GCC. Haiku app compatibility would be good until there is a good technical reason not to.
Atomozero Whether there's real appetite for multi-user support
Yes, though I wouldn't consider it urgent.
Atomozero Whether the existing parallel efforts might want to coordinate at some point
I would love to see all the scattered forks and development efforts unified into one. I do see value to merging the current efforts. However, I wouldn't pressure anyone to do so... if someone wants to have their own thing independently that is fine.
Atomozero How much governance structure we want early on, and how decisions get made
I'd say we need some formality because there will be a lot of decisions to make. I think we need at least 3 people so we can vote on a leader, and vote on major decisions.
Atomozero Infrastructure needs (hosting, CI, possibly a non-profit down the line)
This is important to go from being a bunch of random people to an actual organized effort. It may not be needed day 1, GitHub would probably work for a while. But I think fairly soon (within 90 days?) we would want a website, build server, forums, nightly builds, automated testing, etc. A non-profit would be helpful because servers aren't free.
Atomozero Whether a rough timeline would be helpful, even a loose one
I don't like the current Haiku approach of very ambiguous release schedules. I think we set X number of days after the project starts for the first release, then release every 6 months. At the 5 month mark we branch and take all the latest changes, test for a month, during the test phase only merge bug-fix commits into the release branch, and then release. No release will be perfect, and an operating system is never going to be complete, so let's just stick to something consistent and predictable.
rainygirl I hope a visible release can come out before next summer (winter in the southern hemisphere!).
I'd love to have a first release this year, then every X number of months (I'm thinking 6 months, but could be less). I think the hard part for the first release will be the non-development work. Website, documentation, devops, branding, how to handle bugs from users, etc.
