Large Mailing Lists Survival Guide

November 10, 2017

I initially published this blog post on the Adobe Open Development blog at http://blogs.adobe.com/ (see Wayback Machine), but that’s been archived so I’m re-publishing it here for convenience. Thanks to Adobe for allowing me to spend a portion on my time reflecting on such topics!

Here’s a “survival guide” that we use at Adobe to help our colleagues make sense of our busy Open Development mailing lists.

To send or not to send

TS1. Before asking a question, search the list archives (and issue trackers, etc.) as the answer might already be in there.

TS2. Keep noise low – consider how many people will receive your message. If you’re just saying “thank you” to one or two persons, do it off-list.

TS3. Does your message really belong in an email? If it’s information that’s supposed to last and that you expect future coworkers to know, a wiki, website or blog post is a much better place. Just send the URL of that wiki/website page in email then. Writing more than 3-4 paragraphs is often a sign of something that does not belong in email. And email is where information goes to die!

TS4. Do not cross-post. If you really think other lists might be interested, let them know about your message by sending them its URL, but do not copy the message itself. Cross-posting tends to create split discussions that are impossible to follow.

TS5. Don’t be shy – if a mailing list exists it is meant to be used, so any on-topic question with a sensible subject line is welcome, assuming you do your homework as explained in this guide.

Starting new discussion threads

ST0. To start a new topic, do not reply to an existing message – use the “new message” function of your email client to create a new discussion thread.

ST1. When starting a new discussion thread, include at least one [TAG] in the subject line that points to the product, technology or topic that your message is about.

ST2. The goal of the subject line is to help people decide if they want or need to read your message. If that’s not sufficient, use your first phrase as a summary to clarify. On busy lists, spending time on crafting a good subject line avoids wasting other people’s time, and gives you much better chances to get an answer.

ST3. One question/topic per thread please, it’s much easier to follow, helps people notice your question and makes much more sense in the archives later.

Writing your message

WR1. The shorter your message or reply, the more likely people are to read it.

WR2. Speak in URLs – if something has an URL or unique identifier, point to it. Don’t say “the about page on the new website” or “the memory problem”, but rather http://www.example.com/about and SLING-9362 if the latter is a well-known shortcut to the URL of the actual issue in your tracker. This helps avoid misunderstandings, as well as creating valuable archives with a rich Web of links.

WR3. If you’re describing a bug, include all the necessary information to reproduce the problem, while being as concise as you can: what did you do, what did you expect, what did you get, what was your environment.

WR4. No large attachments or stack traces: open a bug with that info or put it somewhere where people can download it and include only the URL in your message.

WR5. Be direct, ask the root question instead of a derived one. If you need to buy food at 4AM, for example, and you think Burrito Unlimited might be open, asking where can I buy food now is more likely to provide a helpful response that asking where the nearest Burrito Unlimited is. Also known as an “XY problem” where you ask Y but what you really need is X.

Replying and quoting

RQ1. Quote sparingly and precisely. Opinions differ on this, but the lazy top-quoting that’s unfortunately the norm depending on which email client you use tends to make discussions shallow, as it’s impossible to know precisely what people are replying to. So many years later, Usenet quoting still rules on busy lists and/or for complex discussions.

RQ2. Give sufficient context for people to follow your thoughts. Closely related to precise quoting.

RQ3. Remember WR1 – the more concise message usually wins.

Filtering tips

Here are some tips for coping with many emails from multiple high-traffic lists. The goal is to give you the option to quickly skim over the lists traffic to find the few threads that are actually relevant to you.

F1. Have a folder for each list, and a filtering rule that moves the relevant messages there.

F2. To make sure you quickly see responses to threads you take part in, have a special rule for emails/threads that include you. This is a rule that you can have across all your emails: it could be a special “to me” folder, or a different inbox.

F3. To filter out the topics that interest you, set up a rule based on keywords in the subject. Same for people.
This works especially well if people consistently use the ST1 subject line tags mentioned above.

See Also


Apache: lean and mean, durable, fun!

May 19, 2017

Here’s another blog post of mine that was initially published by Computerworld UK.

My current Fiat Punto Sport is the second Diesel car that I own, and I love those engines. Very smooth yet quite powerful acceleration, good fuel savings, a discount on state taxes thanks to low pollution, and it’s very reliable and durable. And fun to drive. How often does Grandma go “wow” when you put the throttle down in your car? That happens here, and that Grandma is not usually a car freak.

Diesel engines used to be boring, but they have made incredible progress in the last few years – while staying true to their basic principles of simplicity, robustness and reliability.

The recent noise about the Apache Software Foundation (ASF) moving to Git, or not, made me think that the ASF might well be the (turbocharged, like my car) Diesel engine of open source. And that might be a good thing.

The ASF’s best practices are geared towards project sustainability, and building communities around our projects. That might not be as flashy as creating a cool new project in three days, but sometimes you need to build something durable, and you need to be able to provide your users with some reassurances that that will be the case – or that they can take over cleanly if not.

In a similar way to a high tech Diesel engine that’s built to last and operate smoothly, I think the ASF is well suited for projects that have a long term vision. We often encourage projects that want to join the ASF via its Incubator to first create a small community and release some initial code, at some other place, before joining the Foundation. That’s one way to help those projects prove that they are doing something viable, and it’s also clearly faster to get some people together and just commit some code to one of the many available code sharing services, than following the ASF’s rules for releases, voting etc.

A Japanese 4-cylinder 600cc gasoline-powered sports bike might be more exciting than my Punto on a closed track, but I don’t like driving those in day-to-day traffic or on long trips. Too brutal, requires way too much attention. There’s space for both that and my car’s high tech Diesel engine, and I like both styles actually, depending on the context.

Open Source communities are not one-size-fits-all: there’s space for different types of communities, and by exposing each community’s positive aspects, instead of trying to get them to fight each other, we might just grow the collective pie and live happily ever after (there’s a not-so-hidden message to sensationalistic bloggers in that last paragraph).

I’m very happy with the ASF being the turbocharged Diesel engine of Open Source – it does have to stay on its toes to make sure it doesn’t turn into a boring old-style Diesel, but there’s no need to rush evolution. There’s space for different styles.


Shared neurons and the Shadok’s First Law of Failure

January 30, 2017

This blog post of mine was originally published by Computerworld UK in 2010.

French-speaking fortysomethings might remember the Shadoks, a two-minute TV comics show that aired on ORTF when I was a kid.

Those silly (and funny) creatures need to get to Earth as their own planet, on the left of the sky, is falling into pieces. They spend their time pumping on bicycle-like contraptions to produce Cosmogol 999 fuel to power their rocket towards Earth, while respected Professor Shadoko keeps them motivated with his motto: “the more you fail, the more likely your are to eventually succeed”. So they keep failing, every single time, hoping that statistics will prove them right some day.

A researcher colleague recently asked me to demonstrate that the work done by Apache communities is more than the sum of the individual capabilities of its members. I think the answer is yes, and that how we cope with failure has a lot to do with it.

Demonstrating this with hard numbers would be difficult, but having been active in Apache projects for the last ten years I can think of a number of examples where what we sometimes call “shared neurons” make all the difference.

It usually starts with a random thought – an often half-baked idea, that might be totally unrealistic or impossible to implement, but is nevertheless exposed to the community as is, and often starts a fruitful discussion. People bounce off each other’s ideas, in a written brainstorm that’s slower than if you were talking face to face, but sometimes more efficient as people have more time to think about their contributions to the discussion.

Brainstorming in the same room is faster, but brainstorming with a worldwide group of specialists – that’s much more powerful than Cosmogol 999, even if it has to happen in writing. But sometimes that turns into a Shadok fuel-producing exercise that fails to produce useful results.

Some Apache (and other) projects use those random thoughts as a first-class design and architecture tool, marking such email discussions with [RT] in their subject lines. This serves as a warning that the discussion is not necessarily about something feasible, it’s more about putting people’s neurons together to shape and refine potentially useful ideas. And sometimes those ideas are just too silly or unrealistic to go anywhere – yet the corresponding discussions stay archived forever on our mailing lists.

Some people are afraid of exposing their unfinished ideas to their communities so early, and having them archived for posterity whatever the outcome. Your idea might turn out to be a stupid one once people nicely demonstrate why it won’t work, or someone might point you to that part of code that does exactly what you were dreaming about, and that you had forgotten about. Silly you.

In my opinion, being ready to accept such failures makes you a much more efficient contributor to open communities. Although you don’t need to fail as consistently as the Shadoks, being ready to fall on your face once in a while allows you to contribute your wildest ideas to the discussion. Combined with respect for other’s crazy ideas, and with the ability to explain nicely when people are wrong, we have a recipe for efficient sharing of neurons, where the sum is definitely greater than its parts.

I’m seeing this neuron sharing in action on our Apache mailing lists all the time, and I think accepting the risk of being wrong when exposing one’s ideas on our public lists makes a big difference. We’re not Shadoks after all – our failure stats are way too low.


Microservices? Nah…Federated Services!

March 17, 2016

As much as I like the microservices concept (*) the name does not really make sense to me.

Why would decoupled services necessarily need to be micro?

Focusing on a service’s size is the wrong crusade for me, I’m happy as long as a service does one thing and one thing well – but that thing might be too large for a micro service.

We had good discussions about this with my colleagues and on Twitter recently, and after some virtual brainstorming it’s my good Apache friend Santi Gala who came up with the Federated Services term (worth a drink-of-your-choice Santi of course, next time we meet!).

I think this describes what we are after much better. Rightsizing makes much more sense than necessarily making things very small.

So here we go, with a Twitter-compatible less-than-140-characters definition:

Federated Services are independently deployable, scalable and swarm-friendly software components with language agnostic interfaces.

That’s it. I don’t think we need more than that to define those services.

WDYT?

(*) I’m working on a blog post about some elements the history of service oriented systems with another good Apache Friend. Stay tuned!


Redeploy OSGi bundles automatically with fizzed-watcher-maven-plugin

September 17, 2015

Being able to redeploy your OSGi bundles automatically when you make changes to their source code is very useful when developing Apache Sling applications, for example.

Today I tried the fizzed-watcher-maven-plugin on a Sling sample bundle, and it seems to work quite well. I just had to add the following to my POM:


<plugin>
  <groupId>com.fizzed</groupId>
  <artifactId>fizzed-watcher-maven-plugin</artifactId>
  <version>1.0.6</version>
  <configuration>
    <watches>
      <watch>
        <directory>src/main</directory>
      </watch>
    </watches>
    <goals>
      <param>clean</param>
      <param>install</param>
    </goals>
    <profiles>
      <param>autoInstallBundle</param>
    </profiles>
  </configuration>
</plugin>

And changing any file under src/main causes the bundle to be rebuilt and (via Sling’s default autoInstallBundle profile) reinstalled in my test Sling instance.

To start the plugin with that setup I used


mvn fizzed-watcher:run -Dsling.url=http://localhost:8080/system/console

See https://github.com/fizzed/maven-plugins for more info.

Filed under: very useful.


Merry Christmas avec la Soupe a la Bière a Roger!

December 25, 2014

Recyclez votre stock de bière à deux balles pour une bonne cause!

La soupe est bonne même avec de la bière à deux balles.

While waiting for the soup to be ready and for the guests to arrive, let me wish all of my readership (yes, both of you guys) a Merry Christmas!

And if you allow me un post en français pour une fois, voici la recette de la dite soupe! Si vous connaissez Roger vous savez qu’on peut lui faire confiance pour ce genre de trucs.

L’alcool s’évapore à la cuisson bien sûr, pas de problème avec les enfants, sauf peut-être que c’est assez corsé si vous faites tout juste.

Ingrédients
Compter 1 litre de soupe pour 4 personnes.

Pour 8 litres: 2 lt bouillon de boeuf, 3 lt potage bâlois (“Basler Mehlsuppe”, en sachets pour ne pas compliquer), 3 lt bière blonde.

4 gros oignons, 150 g beurre.

2 yoghourts nature, 4 oeufs, 1/2 lt crème à fouetter, 150 g fromage râpé.

Ciboulette et persil.

Préparation

Couper fin les oignons et faire revenir dans le beurre, sans roussir.

Ajouter la bière, cuire puissamment durant 15 minutes et 12 secondes.

Préparer séparément le bouillon de boeuf et le potage bâlois.

Verser le bouillon dans la bière, cuire au taquet pendant 15 minutes et 18 secondes.

Ajouter le potage bâlois, cuire à feu moyen. Faire fondre le fromage râpé en remuant.

Battre le yoghourt et les herbes, ajouter les jaunes d’oeufs battus et incorporer en battant à donf.

Cuire doucement pendant au moins une heure et 38 secondes.

Gonfler avec la crème fouettée, au dernier moment.

La soupe se garde bien, elle est même souvent meilleure le lendemain!


Continous Deployment with Apache Sling

September 2, 2014

Today I had the pleasure to attend the Master’s thesis defense of our intern Artyom Stetsenko, titled Continous Deployment of Apache Sling Applications.

Coaching Artyom for this project has been a pleasure, he did a great job and worked independently while listening very well to our advice. He got an excellent mark for his thesis and that was well deserved. Also due to an excellent no-bullets presentation!

I have uploaded Artyom’s thesis paper here, with his permission. The code is available at https://github.com/ArtyomStetsenko/sling-devops-experiments. As the name indicates that’s experimental code, but the resulting Sling-based cluster with automated atomic deployment is functional. Just push an updated crankstart file to the Git repository and the cluster is updated atomically and without downtime.

For me the main goal was to see how we can improve Apache Sling‘s support of modern operations, with continuous deployment, immutable instances etc. I’m continuing my explorations with a Docker-based Sling cluster, the main goal being to create simple clustered environments that allow us to play with these things.

Update: I forgot to mention that my Docker cluster prototype is the basis for my upcoming talk at adaptTo() 2014 on September 23rd in Berlin. The talk’s title is “Apache Sling and devops – the next frontier” and I’ll talk about how Sling can be made more operations-friendly.