Collaborative Working Sessions - Website

Web site WG Notes

note that this session follows closely onward from the Day 2 community collaboration working session.

scope

• someday, we find it nice to have some meta plans about working groups.
  • today we’re going to focus on doing the first one.
• we end up with a few discussion notes here about working groups in a general way, but they are intermingled and non-final.

discussion

• if we want to move the website…
  • currently the code lives on debian’s “salsa” server. (which is a gitlab.)
    • -> this needs to move to some github org.
      • we do not know if we have the reproducibile-builds github org.
        • -> more people who may have access have been contacted, but pending.
  • currently there is a jenkins build.
    • site is a static site, but it is built by jekyll.
    • -> may need to change this to a github action.
    • (this should be pretty trivial. mattia says it’s practically a one liner in jenkins right now.)
  • dns will need to be updated.
    • -> mattia has direct access to this. also holger.
      • and if we need to write new dns entries entirely (github pages may require this)…
        • -> yes that too! yay.
    • -> gandi is the actual host.
    • -> this is ultimately owned by SFConservancy (see notes in billing below).
    • can we have an infrastructure-as-code repo?
      • -> we wish, but the time/ROI here is probably unfortunately not good :/
  • ssl certs…?
    • it’s currently done by letsencrypt.
    • github pages will support a similar thing.
    • we don’t have very exciting requirements here (good).
  • do we have any billing issues to worry about here?
    • -> it seems like “no”! If we’re using github pages, etc, and public repos… this is going to be… free.
    • -> if we do need a credit card for billing purposes… it is possible, but it is based in an organzational conversation with the SFConservancy, so… expect this to require a roundtrip.
  • the minimum viable updates to the website:
    • -> we do not want to do massive website changes here; that is not our goal in this group.
    • -> but we do want to update any links to “where the source is”.
      • and maybe there’s a page in the website about registering for salsa which can be removed.
      • cleanup for debian: the debian internal stuff can also drop some references.
• sidenote: did you know we also own reproducible.build ? do we have interest in that?
  • it’s currently just a redirect.
  • -> it’s neat but we’ll keep it in our back pocket :)
    • we don’t love that you tend to need another conversational RTT to explain “yes it’s a weird TLD” :)
• more website content that is a priority…
  • this is not our primary focus today. there is plenty of that.
  • somewhere under the people page, we probably do want a page that says that there is this working group.
• what else MUST we do before we feel comfortable advancing as a working group?
  • we DO want to communicate transparently that a group will form to handle this topic (and has already discussed it considerably).
    • on rb-general!
    • we’re making a group.
    • of this original list of people {etc}.
    • with the goal of moving the website to a more engagable situation.
    • at the summit, we have discussed several possibilities, and found the greatest acceptance during the summit that… {etc}
    • (we realize that not everything about this option is perfect, but nothing is perfect about any option. here we place the greatest priority on something that we feel is as engagement-friendly as possible, and does not privilege the friction of any particular group over another.)
  • we DO NOT want to communicate that anyone can sign up – not because we want to be exclusive, but because we want a group of a size that is focused enough to get things done.
• we may put some alternative ways to contribute to the website in the website…
  • but it might be something like…
    • “you can send patches to the mailing list if you’re not interested in engaging via github. However you are hoping that someone will do additional work on your behalf to integrate those, and we do not guarantee that :)”
  • could we have more than one active mirror?
    • well maybe.
    • it’s git. we are not afraid of doing this later. that is good and that means we can move forward with incremental steps now :)
• considerations for working groups in the future…
  • a working group can ask for a mailing list
    • (… discussion ensues …)
      • (… something about mailman versions …)
  • “should we distribute pagers?”
    • we’re kidding. we’re kidding.
  • working groups should have some page under the people section of the website.
    • list people.
    • list goals.
    • list any extra communication channels for this group.
      • mailing lists?
      • chat systems?
      • places like github issues also count.
    • list any completion criteria / termination conditions! (hopefully you have them!)
    • will there be an archive of closed working groups?
      • sure. probably. can figure that out later :)
  • working groups should probably have an expiration date and a clear end goal (where when it’s done, the group is done).
  • working groups should probably not have one person. three is a nice number. five is a nice number. bigger numbers are questionable numbers.
  • are you REQUIRED to make a mailing list for a working group?
    • NO.
• guidance for working groups…
  • as a heuristic: a working group should be mindful of accepting contributions if they will create a maintenance burden.
    • It may sound harsh, but we cannot assume continuous future involvement from every person.
  • as a heuristic: do stuff, but think twice before doing stuff that either {locks in future choices} or {has maintenance costs that don’t have a clear future story}.
    • and the inverse: if something can happen later, and nothing we’re doing now blocks that, that’s great. (e.g. git mirror stuff.)
• do we want to form a working group working group?
  • well, maybe.
  • the defacto for this is the people currently in the rb core team (e.g. mattia, holger… shortlist).
    • (we are happy with the people who are involved right now! the discussion is mostly about if there is more formalization and clarification to do.)
  • this might be worth growing.
  • probable domain is:
    • the approval of working groups
    • the garbage collection of inactive working groups!
    • etc.
  • today’s progress:
    • we agree that it’s probably good to start working on some draft thoughts (like some of the above) about what we could do here.
    • we are going to test-run doing this with this website project.
    • we are not going to push any specific procedural policies right now, because that is a bigger discussion, we are not going to be that decisive today, we want to be very inclusive with big policy things… etc.
• WE GOT TEN MINUTES LEFT HERE. WHAT ARE WE DOING AS A NEXT STEP.
  • we do not want to send each other an email on rb-general to ask “who’s awake next monday”, it’s embarassing and it’s noisy and it would be silly.
  • so what
  • one of us doesn’t have an irc bouncer and does not find that funny.
  • so what
  • SO WHAT GUYS
  • (i’m leaving this in the notes because it’s educational to note that PICK THE NEXT THING is actually REALLY HARD and when organizing a working group YOU REALLY HAVE TO FOCUS on PICK. THE. NEXT. THING.)
  • we’re going to agree to a time to continue with one video meeting, amongst exactly ourselves here, because this is hard enough :)
  • OUR AGENDA FOR THAT NEXT MEETING:
    • draft email to announce intentions and process.
    • and work again on defining when we meet next to continue again.
  • WHAT NEEDS TO HAPPEN BEFORE THAT MEETING TO MAKE IT EFFECTIVE?
    • get info/access about the github org.
    • exchange links for where we do the video meeting (it’s probably jitsi).
    • exchange links to a scratchpad editor.