Latest posts for tag pub

Held on 2013-10-27 at Erlug LinuxDay in Bologna, Italy.

Resources:

• Slides for the talk (text)

Held on 2013-08-16 at DebConf in Vaumarcus, Switzerland.

Resources:

• Slides for the talk (text)
• Initial data model for contribution sources

Held on 2013-08-11 at DebConf in Vaumarcus, Switzerland.

Pre-BOF notes

The problem

People seem to identify official recognition with some kind of label. In that sense, you only get official recognition from Debian if you are DM or DD.

I'd like to offer some form of official recognition to non-DDs who are not DM. That can be because they do work other than packaging, or because their packaging work doesn't require DM rights (for example, they may be members of teams that work similarly to the Perl one, or people doing a lot of sponsored NMUs).

I wish this sort of official recognition can also mean that DM can be just a technical mean to a technical end, and loses the "official hat" meaning, so that people don't try to get DM too early, and developers don't advocate people for DM just to give them some kind of recognition.

The proposal

We had this idea before:

1. Create a new label, purely for recognition purposes. Let's say "Debian Contributor".
2. Define something you get for having that label.

But here are some novel implementation details that might just make it work:

1. Give that label to "anyone who has recently done work for Debian.
2. What you get for having that label, is to have your name on a list!

Rationale and details

Now, for recognition, you don't need much more than to have your name on some official list of Debian Contributors. We can list "Current Debian Contributors" and move names to "Past Debian Contributors" if there has been no activity for some time, so that we don't lose credits.

I'd like each name on the list to point to a page which lists the person's contributions, too, so that each person's contribution is credited properly, and we would also have a useful page for NM.

The beauty of the proposal is that the procedure for assigning the label is fully automated, hooking into whatever infrastructure we have to track contributions. That means it's fair, it's low-maintenance, and that to get on the list you just need to Get Some Work Done. Do-ocracy, for labels, too.

Now, unfortunately we don't have infrastructure in place to track all kind of contributions: see more-diversity-in-skills. But that lack of infrastructure does not need to be a blocker.

We can see it the other way round: if a team's contributors don't automatically show up on the list, that is a strong motivating factor for that team to come up with a way to acknowledge their contributors.

This means that by defining our official recognition label in this way, we also create a reason for teams to actually credit their own work properly. This is twisted and evil, and I am proud of it.

Practical/technical issues

This can be something we do at DebConf.

For naming, we can ask each Debian contributor to get an Alioth account, and use it as a handle to refer to the person. That gives us a uniform namespace.

To track work, we need a mapping between Alioth accounts and GPG keys and email addresses. That is something good to have anyway.

TODO: check w/ Lo-lan-do how alioth can keep a list of gpg key id associated to accounts, similarly to what it already does for ssh keys.

Notes taken during DebConf and the BOF

We can also choose not to require people to have an Alioth account and implement our own way of managing which identifiers (login, fingerprint, email, wikinames...) belong to a same person. It is good to give people a choice about their visible identity in Debian.

Some data sources may define 'contributor' status; some data sources extend contributor begin/end times (like mailing lists) as soon as one is a contributor through other things. For example, the Press Team could maintain a static file with a list of member email addresses, and then the press team mailing list archives can be used to see when one has started and ended contributing.

Some lists are populated by real contributors, for example for teams that have a workflow based on subject tags in mailing list posts. Those can be used to define membership and not only timeframe info: it's up to a team to decide.

One needs to be able to opt out, or control which kinds of contributions are made visible.

Email address should not be published by default. One can choose to publish their email address, and/or a description string (for example, to tell the two "Luca Bruno"s apart, and optionally a short bio.

Is it legal? We can make it opt-in by not publishing data by default, and instead mailing people saying «We noticed that you have started contributing to Debian, and we would like to thank you for it. Please click here if you would like to appear in the Debian Contributors page.»

Also, we should not force people to be thanked. People should have a way to control which kind of contributions are made visible, or to remove themselves from the list entirely.

We do not need to look for perfection: if a person isn't credited and can get credited by contributing some more, that's fine. However, if one has done a lot of work already, they should be credited.

Also, coarse granularity is ok. Time resolution could be "a month". It is ok if credits appear/update a day or two after a contribution has been made. Is it ok not to list details of every contribution: I'm just happy with saying "active in the BTS from 2003 to 2013" and link to DDPO.

General rule of thumb: «I'm happy to thank you, but I shouldn't need to go out of my way to do so».

Held on 2012-11-17 at the ubuntu-it meeting in Bologna, Italy.

Resources:

• Slides for the talk (opendocument)
• Slides for the talk (pdf)

Held on 2012-02-05 at FOSDEM in Brussels.

Resources:

• Slides for the talk (opendocument)
• Slides for the talk (pdf)

Held on 2012-02-04 at FOSDEM in Brussels.

Resources:

• Slides for the talk (opendocument)
• Slides for the talk (pdf)

Held on 2011-10-22 at LinuxDay at Centro Congressi dell'Area della Ricerca di Bologna CNR.

Resources:

• Slides for the talk

Held on 2011-07-28 at Debconf, Banja Luka, Republica Srpska, Bosnia.

apt-xapian-index, screenshots.debian.net, distromatch, DDE and some more engine parts for high level app installers

Over the years, people have built several components, akin to engine parts, that can be used to build outstanding high level app installers and other distribution interfaces. Very few people however realise how easy it is, now, to put those parts together into some outstanding new killer application.

As an engine builder I am not the appropriate person to design the car interiors; but I want to let everyone know what working parts are already available, because I want to see people building new, cool, radical, innovative cars.

Resources:

• OpenDocument presentation
• PDF presentation

Held on 2011-07-25 at Debconf, Banja Luka, Republica Srpska, Bosnia.

Resources:

• OpenDocument presentation
• PDF presentation

Held on 2011-01-02 at the KaLUG Mapping Party in Kaohsiung.

Resources:

• OSM technical introduction
• POI + Make your own map

Archive of all posts

eng 654 pdo 550 debian 325 sw 235 tips 123 rant 79 life 76 links 74 talk 67 ita 64 songs 61 pub 60 cazzeggio 53 debtags 50 python 35