Enrico's talks
Last 10 talks
Source-specific metadata
Each source must provide this kind of information about itself:
{
# Machine-readable
name: string,
# Human readable
description: string,
# Optional
url: string,
# All possible contribution types, with descriptions
contributions: [
{
type: matches type in the contributions record,
# Will be added to potfile server-side
desc: string,
}
]
}
Data about one person from one data source
This is the data record provided by a data source for one contributor:
{
# Normally one, if a data source has more and does not know how to choose,
# they can list them all
id: [
{
type: {login,email,fingerprint, wikiname},
id: string,
},
]
# List of all kinds of contributions found in this source
contributions: [
{
# untranslated short machine identifier for this kind of contribution
type: string,
# optional: if missing, defaults to previous 'begin' value. If never seen, defaults to 'today'
begin: datetime,
# optional: if missing, defaults to 'today'
end: datetime,
# Description, from a limited set, since we will collect them in potfile server-side
# optional, points to some team-specific info page
url: string,
],
}
Sending data to the Debian Contributors list
The idea is that data will be sent via a simple HTTPS post, together with a shared secret. Details will follow.
Held on 2013-08-16 at DebConf in Vaumarcus, Switzerland.
Resources:
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:
- Create a new label, purely for recognition purposes. Let's say "Debian Contributor".
- Define something you get for having that label.
But here are some novel implementation details that might just make it work:
- Give that label to "anyone who has recently done work for Debian.
- 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 blog/2012/debian/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:
Held on 2012-02-05 at FOSDEM in Brussels.
Resources:
Held on 2012-02-04 at FOSDEM in Brussels.
Resources:
Held on 2011-10-22 at LinuxDay at Centro Congressi dell'Area della Ricerca di Bologna CNR.
Resources:
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:
Held on 2011-07-25 at Debconf, Banja Luka, Republica Srpska, Bosnia.
Resources: