Enhancing authority of experts in general-interest channels

[yaseppochi]

tl;dr Experts find it frustrating when their ideas don't meet with a presumption of approval, and are annoyed when laymen offer technical ideas that are both obvious and obviously inadequate (to the expert). I call this a lack of "authority", in the sense that expertise that is granted the presumption of correctness, usefulness, and optimality is "authoritative". Below I analyze the sources of loss of authority. I have no technical solutions to offer, but welcome suggestions. [Sorry for sounding like a pompous academic. I'm tired.]

One of the sources of frustration for some developers seems to be lack of respect for their expertise, expressed in terms like "that's a DUMB suggestion; you should ASSUME that WE thought of THAT already and dropped it for GOOD REASON" (exaggerated, of course). While that is out of line, on the other hand the frustration expressed is due to a real problem: experts don't necessarily get authority (here, I mean trust that their proposals are "right" and a bias to approval just because they are the experts) commensurate with their expertise and effort = the responsibility they have shouldered.

I think that part of the problem is that this kind of authority in organizations like Python-Dev is awarded only in part on expertise; the other part is explanation. True, as Eric Raymond points out, we're less susceptible to charlatanry than many organizations. He expresses this as "meritocratic", where the point is that we can recognize real merit and expertise in most cases. But mere expertise is insufficient: one must express that expertise in terms useful to others, both experts in other domains and general users, or it will not be respected as authoritative expertise.

I think the original context of the following text will be obvious to many; please ignore the details, I thought better of it, and suppressed it in that venue for good reason. Nor is this issue in any way restricted to security experts, it just happens at the present time they are salient. But given that context, I think this is a relatively concise expression of some ideas that bear on the subject of this thread: can we find ways to structure discussion so that (over time) experts will be awarded appropriate authority by channel participants?

The rest is a lightly redacted, unposted draft from a Python-Dev thread, addressed not to overload-sig, but to the quoted poster:

I don't like your attitude. It feels like you want me and other contributors to waste time on this topic.

But he is expressing a requirement he thinks is important. He understands that implementing it will have costs. One of those costs is discussion, since it explicitly contradicts a point of your proposal. The actual content is pretty similar to what another poster wrote. The quoted post could have been written in a less presumptive way, but then, you could be a little more tolerant of such expression -- especially given how often you express yourself in the same way.

This doesn't sound like a feature worth breaking compatibility to me.

It does.

It's this kind of response (quoted here in full) that leads me to question the self-appointed security experts. What undermines the authority of experts is the presumption that nobody else knows anything relevant, which is obviously false (except to the expert, an occupational hazard of acquiring expertise).

I trust the expertise. But expertise is by definition narrow, and in practice there is enormous variety of expertise. Good decisions in individual use cases require combinations of expertise. If the different areas of expertise are represented by different persons with different opinions, discussion is required. Your security expertise is important, everybody concedes that. It is not necessarily most important.

Of course you cannot teach us your entire expert understanding of the proposal in one mailing list post (or even a couple dozen). You shouldn't try. But we don't need all of your expertise explained to decide if your assumptions look like our use cases. If there's a reasonable match, we rely on your expertise. If not, you can execute your proposal, but we are left hung out to dry: we don't know if our security is actually being improved.

There are good reasons to be believe that even though your proposals can't be universally "good", they're a good approximation to "the best Python can do for all its users". But that doesn't mean they can't be improved, or that we don't need to be aware of alternatives, questions, and exceptions. There may be alternative ways to address concerns at no or reasonable cost to you. It should be discussed. If it turns out not, we have to do one or the other, but that doesn't mean the discussion is useless.[1]

Bottom line: IMHO, it would be good for Python if the security experts had more authority, and were questioned less, especially about technical details of implementation. But in organizations like Python, authority is awarded on the basis of both expertise (1%) and explanation (99%).[2] IOW, it's an investment: the more explanation you do now, the more we will trust that your view of the world is relevant to our use cases, and the less explanation you'll have to do in the future.[3]

Ball's in your court, security team.

[Meta: that last is harsh -- but remember, I chose not to send it! It expresses a real requirement: to acquire authority, one aspect of responsibility is accountability, ie, the responsibility for (a certain amount of) explanation. Also, "self-appointed expert" would be harsh, but I don't mean that this is a bad thing: after all, who can fully evaluate expertise but an expert? Most experts have a fairly objective assessment of their own expertise! The point is to contrast "self-appointed" with the "authoritative" expert who is not only recognized as such, but also trusted to produce well-balanced, useful proposals by the group.]

Footnotes [from the original draft]: [1] Some discussion is useless. Much of the discussion about os.urandom in 3.5.2 was, for example. I don't know how to stop it, I don't even have a really good idea about reducing it. But I think it would help if the security team invested in authority, as well as expertise.

[2] Of course I'm being ridiculous. Also of course this is a reference to http://www.brainyquote.com/quotes/quotes/t/thomasaed109928.html.

[3] Unfortunately, I can't promise you nobody will demand discussion. What you do get with this kind of authority is the support of the reasonable people when you simply ignore cranks or repeats of the same question already answered.

[dstufft]

On Aug 30, 2016, at 3:20 AM, Stephen J. Turnbull notifications@github.com wrote:

One of the sources of frustration for some developers seems to be lack of respect for their expertise, expressed in terms like "that's a DUMB suggestion; you should ASSUME that WE thought of THAT already and dropped it for GOOD REASON" (exaggerated, of course). While that is out of line, on the other hand the frustration expressed is due to a real problem: experts don't necessarily get authority (here, I mean trust that their proposals are "right" and a bias to approval just because they are the experts) commensurate with their expertise and effort = the responsibility they have shouldered.

For what it’s worth, as someone who is one of those “experts” (I hesitate to call myself that, but I am more knowledgable than average?) on security and as one of of the folks who got burned out on python-dev from the security related discussions it was never really the need to discuss changes that caused the most pain for me personally. Some of the pain was technical, some of it was cultural and I don’t think overload-sig is going to solve the latter but it can likely solve (or reduce at least) the former.

From my end of things here is what made the discussions personally toxic and lead me to unsubscribe from python-dev:

The topics were obviously heated, which cannot be avoided when you throw a bunch of opinionated people into a single place, but the nature of mailing lists creates a dog piling effect. People don’t read all of the recent messages before responding (and mail clients often make it hard or difficult to ensure that you do this) so they typically don’t see that someone already raised some point and so they want to make a point and they respond… which is reasonable, except when 5 other people already made that same point it quickly turns into a feeling of having a bunch of people dog pile on you.

Email lacks a real ability to multi-quote (to my knowledge?) so if I see 5 people making the same point (or a similar), I cannot easily group them up into one email and respond to them all at once. I have to either only respond to one of them, or I need to respond to all of them (often times, you feel a need to respond to all of them because the points are rarely exactly the same, but similar enough that it makes sense to group the discussion at once). In addition, the lack of multi quote means if you want to respond to multiple disparate people/emails you’re forced to generate multiple emails yourself. This causes the email volume to expand on “lively” threads as you might start with 1 email, get 3 people to respond with 1 email each, then you need to respond to those three emails with one email each, and other people also respond to those 3 people, then those people feel a need to respond to all your emails… and it quickly compounds upon itself to where it just feels like a constant barrage of email coming in.

In the vein of “too much email is generated”, the discussions often end up becoming circular, however it’s hard to generate a link back to a previous iteration of the same discussion even within the same thread. As the threads get larger with more email, people will start chiming in who were previously ignoring it (often without reading the entire thing, because long threads == hard to read the entire thing), often making the same points someone else did causing things to get rehashed again. I can find the previous discussion in the thread in my personal email client, but it’s hard to take that and tell someone “No, this was already discussed, see ”. The best I can do is try to find it in piper mail… but piper mail is pretty horrible for following along on a thread since it’s sort of threaded but just kind of gives up part way through and starts rendering a flat list in seemingly random order. It’s also difficult to actually go from a message in my inbox to the link on pipermail, often times forcing me to reread large parts of the thread to try and find the one I’m looking for.

In the end, I had to unsubscribe from python-dev and that was because of a technical limitation as well. I couldn’t hide a single thread from continuing to send me email nor could I follow it reasonably through anything but email. So my only option without spending a bunch of time mucking around in my filters (context: I currently have 0 filters, everything hits my inbox) was the nuclear one where I just bailed completely to make it stop.

The cultural problems (for the security side) were less about being upset that someone challenged our proposal (although I’m sure it gets to that point, because things start to get heated) but more that, having made multiple proposals to changing CPython and watching countless other discussions happen, there’s a feeling that when a non-security change that might be backwards incompatible is proposed, the discussion tends to focus on trying to determine whether or not the change is worthwhile enough to justify the cost of breakage. Whereas it feels that there is a higher bar for security changes and as soon as you suggest making any change that might ever break someone’s running program, you get a multitude of people drawing a hard line saying that Python does not break backwards compatibility (which is demonstrability false).

Anyways, I think the biggest technical hurdles are that mailing lists (and the lowest common denominator problem that occurs when the MTA is your primary UI) tend to generate a lot of email because it’s lacking features that help to reduce the amount of email generated. This tends to compound as the threads get longer people are less likely to have read the entire thing, causing even more email to be generated as the discussion starts becoming cyclical. My experience has been that the answer to this has traditionally been to develop your own, personal pipeline for email that can better handle the deluge of email that a lively email discussion can produce instead of using a consumer grade MTA mostly out of the box— but personally I think it is far better to try and centralize the solution(s) to make it easier to apply these problems across the whole population.

— Donald Stufft

[warsaw]

On Aug 30, 2016, at 12:20 AM, Stephen J. Turnbull wrote:

I call this a lack of "authority", in the sense that expertise that is granted the presumption of correctness, usefulness, and optimality is "authoritative".

Thanks Steve for starting this discussion. I think there's a lot of useful insights here.

Authority in such a diverse project as Python is, as you point out, a difficult thing to identify, and I suspect even more difficult to assert. But let's say for the moment that we can all agree that Person X is an expert in crypto and security. Are they also an expert in the use cases for those APIs? Are they also an expert in Pythonic API or language design? Are they also an expert in long-term software maintenance, integration, downstream relations, and community guarantees?

I'm not saying they're not, but because some topics are so tentacled, it can bring a lot of different experts into the discussion, all of whom are going to have different perspectives and "authority". I think a lot of the burnout occurs when these different perspectives are in conflict. We usually aren't good at resolving these conflicts in whatever medium we choose, although I'll say that it does happen (e.g. PEP 493), and I think face-to-face conversations are generally more successful.

We don't have good ways to break ties, except to appeal to the BDFL. Guido really is the only person with the ultimate respect and authority to shut down discussions with a pronouncement. That's a community problem that I think we do need to address. (It's great when Guido does pronounce, and I can say from experience that even if you disagree with the decision, it's usually a huge relief that a decision was made so we can all just get on with things.)

BDFL-delegates serve this purpose during the PEP process, but they have to be perceived as impartial. We could use more of them.

On Aug 30, 2016, at 05:25 AM, Donald Stufft wrote:

The topics were obviously heated, which cannot be avoided when you throw a bunch of opinionated people into a single place, but the nature of mailing lists creates a dog piling effect. People don’t read all of the recent messages before responding (and mail clients often make it hard or difficult to ensure that you do this) so they typically don’t see that someone already raised some point and so they want to make a point and they respond… which is reasonable, except when 5 other people already made that same point it quickly turns into a feeling of having a bunch of people dog pile on you.

I wonder if there's a way to short-circuit this problem through the use of proto-PEPs, Google Docs, or some other editorial mechanism. We invented PEPs because Guido couldn't read every message in a thread and make a reasoned decision about a particular language feature. PEPs are a way to condense and summarize proposal, but also a living document (until accepted) to outline open and contentious issues, and to acknowledge alternative approaches. These things are useful in the heat of a discussion not just after everything has more or less settled down.

I don't know if it would help, but if such a document were started early, and it was lightweight enough to easily edit (and comment on?) then maybe you could shut down rehashes by pointing to the proto-PEP. You might even preface all your responses with:

Current status: url-to-pep

and then just ignore any responses that rehash the same thing over and over again without adding any value.

Just as an aside: I understand that everyone uses different tools for their discussions, but the MUA I use doesn't make it all that difficult to do multi-responses, as this email shows.

(Odd aside #2: when I know the response is going to a tracker, I don't like to include a closing signature even though everything else about this response looks like a regular mailing list response to me. ;)

[gvanrossum]

@dstufft Your feeling about how the tools (seem to?) impede the discussion moving forward is exactly how I feel 80% of the time when reading Python-dev or Python-ideas. But I can't unsubscribe. :-) Fortunately I can mute GMail, and I actually have a few filters (e.g. anything by Sven R Kunze is hidden from view since despite his obvious technical chops his words are frequently infuriating).

Regarding the feeling that security fixes are burdened with more backwards compatibility constraints than regular changes: that's an eye-opener for me, because actually those requirements are relaxed for security in ways that they never are for regular change proposals. (E.g. no matter how beneficial, you can't get new features added to Python 2.7, except for security issues, and IIRC there has been a case where a particularly insecure argument was simply dropped from an API in the next major release, without a deprecation period.)

I can't put my finger on why it feels to you like you are getting more pushback for backwards compatibility reasons -- maybe it's just that if it wasn't security nobody would consider those types of changes to an API at all (e.g. the change in behavior to os.urandom in 3.5.2) so you never see those discussions -- they simply don't take place because everybody knows you can't do that. (I learned my lesson when I introduced bool in 2.2.1).

[yaseppochi]

@dstufft How did you get that attribution line? There doesn't seem to be any way in the comment box.

as someone who is one of those “experts” (I hesitate to call myself that , but I am more knowledgable than average?

Which is exactly what I meant by "self-appointed expert who's got an accurate evaluation of his own expertise". Sure, you may not be Bruce Schneier or Peter Newman, but then Guido isn't either, and "being Dutch" isn't quite enough. :-)

Email lacks a real ability to multi-quote

AFAIK, it's not email, it's the MUAs. I'm pretty sure that the threading algorithm used by IMAP THREAD plus the ability to add all cited message IDs to references in topologically sorted order would do the trick for merging threads, and merely quoting text from multiple messages or selections is almost trivial since the mail is text/*. But I concede there are few MUAs, none of them popular, that make any of that straightforward, let alone do it automatically.

My experience has been that the answer to this has traditionally been to develop your own, personal pipeline for email

If in "personal pipeline" you include filters such as killfiles, sure, but I've never found maintaining those particularly burdensome (definitely not compared to not maintaining them! :-) A good MUA makes it pretty easy: decent MUAs allow muting a user or a thread with one gesture (a click or a hotkey). Configuring a good filter is hard, so you need to do that by hand, sometimes with a glob or regexp, unfortunately. (Eg, the Nikkei news group has about 10 email aliases in 3 domains, so you really need to filter on the corporate domain, but I don't know any one-click filters that really do "messages like", they do an OR on all the senders or something similarly inadequate.) Unfortunately (for me, anyway) we are not going to be able to persuade people to give up AOL, Yahoo! and GMail, so "better MUAs" is not a solution.

The best I can do is try to find it in piper mail… but piper mail is pretty horrible for following along on a thread since it’s sort of threaded but just kind of gives up part way through and starts rendering a flat list in seemingly random order.

It's still using the same principles for ordering as before, it's just that you have no clue which parent any given post attaches to. GMane and others have a better UI for that. I think HyperKitty does too, but I haven't seen enough long threads in a Mailman 3 list to be sure.

I think it is far better to try and centralize the solution(s) to make it easier to apply these problems across the whole population.

It's a step backward for me. At least in the incarnations I've tried so far. But I can deal with them, and many people seem to like them.

Also, I think encouraging synchronous posting (where at the very least you have a chance to look any posts that may have been posted while you were composing before actually posting) is the best way available to reduce "dog piling" and concurrent thread splitting. It also encourages more "linearity" in general, so (one may hope) faster convergence. I'm hoping HyperKitty can help a lot so we can stick with the Mailman family, but we'll see.

Whereas it feels that there is a higher bar for security changes and as soon as you suggest making any change that might ever break someone’s running program, you get a multitude of people drawing a hard line saying that Python does not break backwards compatibility (which is demonstrability false).

I have no objective way to measure, but I think the problem is not a higher bar, but more that security changes cause a lot more breakage a lot more obviously than most of the backward-incompatible changes that sneak through, and they do so intentionally (not as a side effect of a bugfix or enhancement), so draw more adamant opposition. A second issue is that many end users' workflows depend on insecure practices because the servers they need to connect to are misconfigured. Sure, that's horrible, but the end users and their IT support are not pleased because they can't do anything about server config, that's controlled at corporate central. Finally, there's also the "Paul Moore" effect: you learn to distrust anything security people say because they seem to be evaluated on how much annoyance they can cause without really increasing security. As Paul himself points out, that does not apply to the PSRT, but there's this meme he admits he has to consciously suppress. :-(

Whether it's a higher bar or more noticable breakage, I suppose there's something to your feeling that opposition to security-related changes is greater and more intransigient than for the general case.

[yaseppochi]

Aha! GitHub does not synchronize posting (the post I just made sat in the browser for an hour or so, and there was no indication that Barry and Guido replied during that period). Fortunately, I don't think that there was all that much redundancy across messages. Or maybe it's a property of the group, not just luck?

[gvanrossum]

GitHub does not synchronize posting

Hm, that's strange. I thought it did; sometimes when I am working on a reply to a PR, a note with another reviewer's comment shows up (though it's easy to miss). However maybe PRs and issues are treated differently (even though they share many common traits). But I've also noticed that (typical for such JS features) when there's a timeout (e.g. my laptop is suspended, or my train is in a long tunnel) the JS code just seems to give up and notifications stop until I've reloaded the page.

[gvanrossum]

Also, the email notifications sometimes arrive in a different order than they are displayed in the web UI.

[dstufft]

@gvanrossum said in https://github.com/python/overload-sig/issues/3#issuecomment-243495745

Regarding the feeling that security fixes are burdened with more backwards compatibility constraints than regular changes: that's an eye-opener for me, because actually those requirements are relaxed for security in ways that they never are for regular change proposals. (E.g. no matter how beneficial, you can't get new features added to Python 2.7, except for security issues, and IIRC there has been a case where a particularly insecure argument was simply dropped from an API in the next major release, without a deprecation period.)

I can't put my finger on why it feels to you like you are getting more pushback for backwards compatibility reasons -- maybe it's just that if it wasn't security nobody would consider those types of changes to an API at all (e.g. the change in behavior to os.urandom in 3.5.2) so you never see those discussions -- they simply don't take place because everybody knows you can't do that. (I learned my lesson when I introduced bool in 2.2.1).

Yea, there is definitely not a 1:1 mapping here (and honestly, the backport of HTTPS validation and the better ssl module to 2.7 was a pretty huge win), so I don't mean to sound like it always comes across that way. Security also has the sort of crummy aspect that it's job is sort of to take code that already "works" (or at least, executes) and make it stop doing that (ideally only because of an attacker doing something unsafe, but there are always false positives) and if you're not someone who is security minded or who cares it's easy to see security as that thing that breaks my code. There is a lot of emotion wrapped up in this as well, so it's entirely possible (and likely) that this affects me more because I've been on the receiving end of the mailing list dog pile more than once for these kind of changes (hell, one of the first things I ever did with the Python community was fight for valid HTTPS on PyPI years ago). I tend to have a habit of finding hills to die on :)

@yaseppochi said in https://github.com/python/overload-sig/issues/3#issuecomment-243506167 Finally, there's also the "Paul Moore" effect: you learn to distrust anything security people say because they seem to be evaluated on how much annoyance they can cause without really increasing security. As Paul himself points out, that does not apply to the PSRT, but there's this meme he admits he has to consciously suppress. :-(

Yea this is a real problem that the security community as a whole has often focused on absolute security with little regards to usability (IMO a 95% solution that will get used 99% of the time is better than a 100% solution that will get used 20% of the time) and brain dead policies that do little, nothing, or are outright harmful but cause a noticeable annoyance leads people to view security as a whole as the enemy. Sadly there's a (perfectly understandable) guilt by association thing, but I think (hope?) that the Python security community does a reasonably OK job at focusing on the 95% for the 99% solutions and not the 100% for the 20% solutions.

@barry said in https://github.com/python/overload-sig/issues/3#issuecomment-243482865 Just as an aside: I understand that everyone uses different tools for their discussions, but the MUA I use doesn't make it all that difficult to do multi-responses, as this email shows.

Yea, I probably should have said all of the MUAs I have used or something. I've never used anything particularly fancy or powerful, Outlook when I was on Windows, then Gmail, then Mail.app on macOS and iOS along with whatever the webmail client Fastmail uses. I could probably reduce some of the burden by investing more in actually figuring out my tooling to make these lists feel less like an onslaught of email by putting them in folders and keeping them from popping up a notification. My reasoning for not is more stubbornness than anything else, I treat my local config as largely ephemeral so I tend to roll with defaults for most things so I can easily wipe my machine and reinstall on a whim (and I do that every 6-8mo or so). I do think there is some value though to thinking about what the "just uses their consumer grade standard MUA defaults" crowd experiences, although I also think it's not unreasonable to say that folks like me might be a minority in the developer circles (though I'm not sure that they are, it's hard to know!).

[dstufft]

As the resident, "let's use discourse!" guy, I will mention that discourse does have a feature that let's people have titles associated with their accounts. I didn't really enable these at all because I thought they were kind of silly (do we really need a "BDFL" title next to Guido to know he is in fact the BDFL?) but one possible use case for them could be letting people advertise their "core competencies". I'm not sure how useful that really is though. They would show up something like

Donald Stufft dstufft Packaging/Security

You can see an example of them at https://meta.discourse.org/t/can-a-user-edit-their-user-title/26681.

Like I said, no idea if this helps at all or not, but thought I'd mention it.

[gvanrossum]

A problem with that is that authority is not conveyed by the expert assuming authority -- it is bestowed upon them by the community, gradually, based on reputation, and each community member may have a different sense of who is an authority on what. I don't have a good answer for how to educate new members quickly on the status of various community members' reputations. Maybe StackOverflow's point system could work.

[dstufft]

A problem with that is that authority is not conveyed by the expert assuming authority -- it is bestowed upon them by the community, gradually, based on reputation, and each community member may have a different sense of who is an authority on what. I don't have a good answer for how to educate new members quickly on the status of various community members' reputations. Maybe StackOverflow's point system could work

These titles are tied to badges and groups, so it's possible for moderators to assign them to people, might be possible to make them earned naturally too I'm not sure. These are not things really where random people get to assign free-form text to their own account, but are values provided by the admin/mod team.

[gvanrossum]

I suppose the admin/mod team after a while (well, several years) get really tired though and just stop updating the titles.

[dstufft]

Yea that is entirely possible! I don't think it's any sort of an amazing solution, just wanted to mention it as a thing that exists.

[yaseppochi]

@gvanrossum "Authority is bestowed" is very much what I'm trying to get at. I think it's based on two components: expertise and impartiality, the ability to step back from your own perspective and listen to others.

@gvanrossum Yes, I think I was AFTK long enough for a script to time out and stop phoning home. A few minutes ago I did see Donald's post when I scrolled to the top of this comment. So mostly it works. I wonder if it would be useful to require confirmation if there are unread posts between starting reply and hitting "send". Obviously that can't work with email, but for people working with the web interface it could have a useful effect.

@dstufft Thanks for mentioning titles. I think "BDFL" could be even counterproductive (not everything Guido writes is a pronouncement!) On the other hand, a lot of people don't know what to do about security or code of conduct or legal. "PSRT", "Moderator", and "PSF Lawyer" could be of some use if somebody needs to report an exploit, harassment, or abuse of trademark. And mark of authority based on badges is worth thought, though it depends on the badges available (and for "vote-based" badges, proper framing of what's being voted for -- I don't think collecting 100 QOTWs should mean automatic promotion to committer :-).

@warsaw There is no efficient way to break ties except to appeal to higher authority. That's what "tie" means. Sometimes agreeing to disagree works, but if you do that too much, you end up with "let's make everything an option", which is unwieldy and ugly. Sometimes "let's all sleep on it" leads to a compromise in the morning. Recently there have been a spate of specialist papers on "random dictatorship", which has nice mathematical properties but I doubt would work at all in practice. Which leaves you with higher authority: nothing else works all the time, and sometimes nothing else works.

[gvanrossum]

not everything Guido writes is a pronouncement

Alas, some people do interpret anything I write as such, and I've gotten in trouble for it many times (though mostly off-list).

[dstufft]

And mark of authority based on badges is worth thought, though it depends on the badges available (and for "vote-based" badges, proper framing of what's being voted for -- I don't think collecting 100 QOTWs should mean automatic promotion to committer :-).

The discourse badge system is more or less fully customizable. It ships with some default badges for some silly things like "First Reply!", but you can delete those badges (or disable them) and provide your own badges for whatever you want. Badges are awarded based on SQL Queries that you enter so you can do things like shove committer information into the PostgreSQL database, and setup a badge that gets awarded automatically whenever someone becomes a committer.

One big downside to this system is that you can only show one title (so to use myself I would have to pick between "Security" and "Packaging") but the badges "earned" would show up on the user's profile page.

Overall, I don't know if it would actually be helpful or not. I think it has potential to be so, but in practice it may fall down as just being misc noise.

[yaseppochi]

Another interesting discussion probably mooted by various experiments in communication. Closing.