Nobody volunteered *up front* to take notes for the Matrix design session [1], but I did end up taking a few notes, so agreed to do some follow-up.
The general issue seemed to be how difficult it was to pull out "signal" from "noise" (where "noise" is individual; i.e., something completely ARM-specific would be "signal" to the ARM maintainers, but might be "noise" to someone else). We also talked about a few other things that could potentially be improved. The decision was to make a guidelines page we could point people to quickly, with points like the following: --- - Please when possible, reply in thread, even for short things. If you realize you haven't replied in thread, please start as soon as possible, and before replying, look for threads. - If there's been a technical discussion that has reached an agreement or conclusion, try to remember to @ relevant people saying something like "any thoughts"? Just to make sure they have an opportunity to weigh in. - Also consider whether it would be good for posterity to paste the entire thread onto xen-devel, for wider discussion. (We used to do this a lot more for IRC conversations.) - Don't be shy about asking people to move the discussion to a more appropriate channel. - We may at some point consider having more specific sub-channels. In most cases the core maintianers would need to be part of all the channels anyway, but having multiple channels still helps, by 1) breaking down the stuff to catch up on into smaller chunks 2) sorting it into bits which should be easier to skim. e.g., x86 maintainers would skim through the backlog on an ARM channel fairly quickly, while spending a lot more time going through the backlog on an x86 channel. - For patches, console logs, etc longer than a few lines, please use a pastebin. We recommend either paste.debian.net, gitlab 'gist', or termbin (instructions for termbin below). --- Any thoughts? [1] https://design-sessions.xenproject.org/uid/discussion/disc_Dp9L1y1poJPV69rgUjYO/view
