Jump to content

User:RobLa-WMF/Blog

From mediawiki.org

2016-09-06

[edit]

Wikitech-l

[edit]

Discussing my response to Quim's email about WikiDev17 on wikitech-l made me wonder "do we have a 'wikitech-l' page?". Answer, not really, just a Wikitech-l redirect to "Mailing lists". Given the central role that wikitech-l plays in many technical decisions, it seems we should have a better landing page for it. So, I'm starting one at User:RobLa-WMF/Wikitech-l.

2016-09-04

[edit]

Vector formats

[edit]

A while back, there was some discussion of vector formats on Phab. @Brion's recent musing about HVIF made me curious to start digging things up. I really shouldn't spend a lot of time on this right now, but I'm leaving this as a breadcrumb for myself (or others who want to ask me what I've learned). Page which I'll hopefully expand on this: User:RobLa-WMF/vectorgraphics

Good enough

[edit]

I suppose I should mention the blog post from a couple of weeks ago here:

2016-08-01

[edit]

I need to write up User:RobLa-WMF/Nachvollziehbarkeit (/me waves at User:Daniel Kinzler (WMDE))

2016-07-29

[edit]

My edits

[edit]

Wrapping up my last couple of weeks, here's some of the stuff I've edited here:

2016-07-12

[edit]

ArchCom speed

[edit]

I wrote User:RobLa-WMF/Consensus in response to some concerns I had heard about the speed of ArchCom. Still very rough draft stuff, but I'm capturing this here for my own purposes.

2016-06-30

[edit]

ArchCom Status

[edit]

I'm thinking of adding some transclusiony magic to Architecture committee/Status, since it seems like the updates are a little tough to make in the current form. ArchCom is doing a fair amount of editing of that page, but it's not clear it's truly useful yet. More to think about.

In the meantime, I'll continue updating my end of quarter/end of FY stuff.

2016-06-01

[edit]

Conpherence

[edit]

2016-06-01: This is a placeholder for me to describe why I'm starting to push Conpherence in Phabricator. In short

  • Persistent, linear conversations, in a format that discourages long-form rants
  • The "anti-feature" of poor real-time support is a blessing in disguise (IMHO). The lack of real-time support discourages the implicit expectation that responding to a message quickly deserves a quick response "while I have your attention"
  • The integration with the rest of Phabricator is great.

For people that are expecting Slack/IRCCloud/Mattermost/etc realtime support, it will be disappointing. It's not all that, and may never be. That's ok; it's still useful for persistent conversations that would otherwise be tied to a Phab task (i.e. Maniphest); the conversation doesn't have to be "tracked" like a task is.

2016-04-11

[edit]
(Monday)

Loafers

[edit]

During Real Time Editing session at WikiDev '16 (T112984), User:Guillom noted some interesting collaborative editing research:

and there's a paper I wasn't able to read yet ( http://paul.is/pubs/andre-coordination-chi2014.pdf ). But going through the use cases and asking what we need for each might clear up some of these difficult questions.

Summary of the paper: they ran a study regarding collaborative, creative tasks. The test experiment involved getting subjects to create limericks using Etherpad, then comparing the solo work versus the collaborative work. Simultaneous editing runs the risk of social loafing, which seems to be mitigated when everyone understands their role. Their most successful test runs involved having one person assigned as the writer, and a second person assigned as the editor.

This comports with my Etherpad notetaking experience. When we have a large enough group, we often end up with pretty good notes, but that is frequently through diligence of one notetaker, and then many after-the-fact corrections from everyone else. We should put some thought into how to split up the roles of notetaking to make it possible for multiple notetakers to jump in. Even if we don't coordinate these roles beforehand, just having a language to describe the roles can do wonders. For example, in a couple of the QRs this morning, I ended up being the self-designated "section header person", dropping in placeholders for "Slide 1", "Slide 2", etc, and then copying in the slide titles into those sections.

We then had an outline which (hopefully) made the result easier to work with, and helped me follow along. I say "hopefully" because my effort during the first QR was completely uncoordinated. It could have been annoying. Did it work? Is there a more efficient way of codifying multiple notetaking roles? Can we bark "get to work!" to our social loafers?  :-)

2015-12-10

[edit]

Conversation slow start

[edit]
See User:RobLa-WMF/Conversation slow start

I have a lot of thoughts about applying Van Jacobson's slow start algorithm to conversations. It involves asking a group one question, then two, then four, until you hit a pace that matches the cognitive bandwidth of the group you are speaking with. I think bikeshedding is a symptom of congestion collapse, where someone puts forward something big and important, and people trying to engage start with the tiny piece they can actually understand.

2015-10-29

[edit]

Back from my trip

[edit]

I was on the road for most of October (in Missouri, Kansas, and Colorado). Maybe I'll post something about it here one of these days.  :-)

RFC review meetings

[edit]

RFC review earlier this week:

Upcoming meetings:

2015-09-28

[edit]

Scope of WikiDev16

[edit]

I wrote up Wikimedia Developer Summit 2016/Scope after merging User:RobLa-WMF/WikiDev16 into it. I sent mail to wikitech-l highlighting this change, but haven't gotten a response as of 2015-09-29 noon-ish PDT.

2015-09-22

[edit]

Dogfooding

[edit]

The English Wikipedia article on eating your own dog food is interesting to me. To quote:

The development of Windows NT at Microsoft involved over 200 developers in small teams, and it was held together by Dave Cutler's February 1991 insistence on dogfooding. 

Indeed it was. I worked in several internship/contractor gigs at Microsoft in the early 1990s, and I remember the days of dogfooding Windows NT well. The NT team was relentless about shaming any non-NT holdouts into switching to NT. Given my affiliation and affinity with Microsoft ITG (basically, Microsoft's much larger equivalent of Wikimedia's TechOps group + Office IT group), my younger self thought it was ridiculous that they were switching away from a perfectly functional Xenix-based email system.

The reason why I bring this up is that it seems "of course, dogfooding is good" has become a bit of unquestioned folklore. I realize now that dogfooding was the right strategy for Microsoft circa 1991-1995, given what they were trying to accomplish, which world dominance of Microsoft operating systems. Often, in the same spirit of camaraderie, we wolf down the dogfood and hope it will somehow make our software better.

Sometimes, a non-Wikimedia system may be the best foodtool for the job. At WMF, we shouldn't compromise on our guiding principles, but we shouldn't insist on using our own systems when a system developed and/or maintained by someone else would be the best tool for the job. We shouldn't seek world dominance.

2015-09-18

[edit]

Demonstrating leadership at WikiDev16

[edit]

I had a great conversation on #mediawiki-parsoid and then #wikimedia-tech with many folks, which was in many ways a back-and-forth with cscott. As I've said many times before, I'm thinking a lot about IETF as my model for how to do large scale collaboration, and what I'd like WikiDev16 to be more like. My main point in my conversation with cscott is that WikiDev16 is an opportunity for anyone to demonstrate technical leadership in the Wikimedia community, and that no one should be waiting for "management" to give them approval to do it.

Part of the reason for engaging in the conversation with cscott is that that I think people are (rightfully) confused about what to propose for WikiDev16. I've admittedly had a tough time communicating what I hope, in large part because it's very difficult to boil down my years of experience with IETF stuff into something short and pithy. My main point is "let's try to make this like a good IETF meeting". I proposed sending a scout to the next IETF meeting to make it a little easier for me to communicate this. I've also pontificated at length about this in User:RobLa-WMF/WikiDev16

2015-09-17

[edit]

Registration for WikiDev 16

[edit]

Just completed this, and created a stub page where I'll be putting my sessions.

2015-09-16

[edit]

2015 FYQ2 goals (draft)

[edit]

I'm running behind on Q2 goals drafting. I was tempted to coopt part of the last Architecture Committee meeting for this, but decided against it because we had a lot to talk about.

Here are the draft goals that I'm putting forward for "Architecture":

  • Prepare WikiDev '16 ("Focus" goal)
    WikiDev '16 is an opportunity for us to demonstrate that we can develop a modern system in an inclusive, consensus-oriented, open manner. We need to learn from other organizations that have built popular, complicated systems in an open manner (e.g. IETF). We need to have large number of RfCs from a wide spectrum of product areas, with ample discussion *prior* to the event for each and all of the RfCs, and WikiDev '16 established as an opportunity to settle many stalled issues.
  • Improve ArchComm utility ("Strengthen" goal)
    We need to make sure the Architecture Committee is set up to succeed, and understands the urgency and importance of its work (including among the members of the group). A goal is to maintain at least one IRC meeting per week, without typical lament "we're not sure we have anything to talk about this week".
  • ArchComm naming ("Experiment" goal)
    Our terminology is loaded. Terms such as "RfC" and "Architecture" mean many different things in Wikimedia and in the world generally. The Architecture Committee is composed of members with demonstrated talent to lead building great software in an inclusive, consensus-oriented, open manner. The Architecture Committee will need to better establish what its role is, and we may need to rename the "Architecture Committee" to clarify what is/isn't in scope for it.

As of this writing, the members of the Architecture committee hadn't seen this writeup or known what I was planning to put in these goals. Everyone (ArchComm included), let's use the talk page to discuss this.

2015-09-12

[edit]

Good meeting hygiene

[edit]

My focus this past week has been thinking about how the ArchComm can be more effective. I think we're making incremental progress there, but it's not without pain. I've been much more strident about good meeting hygiene, with clearer agendas, taking good notes, etc. That's not to say that I've done a great job of leading by example, but it's something I'll be pushing myself to be better about.

At my urging, we switched over to using Google Docs rather than using Etherpad, which pains me in many ways because of the (hopefully temporary) switch to a proprietary system. I would like to be able to take notes in meetings in a way that participants feel comfortable saying things that are confidential, and not have to worry about their comment being taken out of context in the public record. One way that I think we can do this is having discipline about reviewing meeting minutes in real time, especially in those cases where the participants know the minutes will be published publicly. Our Etherpad instance doesn't have good authentication, and doesn't have good offline behavior, whereas GDocs works relatively well when the connection is flaky and/or the server is flaking out.

IRC meeting

[edit]

I think Phab is working pretty well as a scheduling tool, despite the rough edges. The IRC meeting earlier this week (task TE61) went well. I still need to make sure the transcript is posted and make sure that next week's meeting is announced.

2015-09-02

[edit]

Architecture Meetings

[edit]

The main focus of my work today was the Architecture Committee work from today; first the smaller committee meeting then the IRC meeting. There's a lot of work needed to make this process make more sense to everyone. I have a number of action items out of this that I need to follow through on; for example, making it so that the setup and wrapup from the meetings isn't laden with a ridiculous amount of weird little scripty bits, but instead, we actually have the preparation and the followup from this meeting focus on the content, and not the tools.

Wikimedia Developer Summit 2016

[edit]

I've been thinking a lot about this, and will probably jot out a little something for wikitech-l. I've already filed a couple of Phab tasks, and gave my spiel about us needing to learn from the IETF. My disappointment thus far is that some of the realtime responses I seem to get have the emotional feeling of "ah, that's nice you're passionate about this, but meanwhile, there's more important work to be done. More important people than you are asking me to do more important things. Don't worry though, because ... I ... wouldn't want... you ... to be uncomfortable or anything"

I may be underestimating the impact this idea has, and that I need to just be persistent. I'm sure that there is a lot of legitimately important work that needs to be done, but I also get the feeling that there are a lot of people that are freaked out by what they think their managers are telling them, and feeling overly pressured by the demands on their time. We've got a lot of really important work and thinking to do, so it would be tragic if instead we instead focused on "manager happiness" as our primary metric.

2015-09-01

[edit]
RFC review meeting set up for tomorrow
[edit]

See my wikitech-l email for more on this. One day, I might even link this

Maintaining a blog here

[edit]

I'm going to try out maintaining a blog of my work stuff here. There are many, many ways in which this is probably the wrong tool for the job ("where's my RSS feed?"), but I'm doing it as an experiment in using some of our latest tech. Mmmm, tasty dogfood.

Retrieved from "https://www.mediawiki.org/w/index.php?title=User:RobLa-WMF/Blog&oldid=2232282"