Date   

Re: I claim "bus factor" is mostly useless

Daniel Stenberg
 

On Tue, 20 Jun 2017, Wheeler, David A wrote:

It's valuable for users to know that even if the current lead died, the project could simply continue. The basic issue here is that we're all mortal (vulnerable to being "hit by a bus"). Even if the project is popular, that doesn't mean that it can be easily continued if the lead disappears.
My claim is simply that you cannot figure out how easy, how hard or how likely that is based on this "bus factor" number. I claim that you instead wrongly fail to appreciate well-run small projects by this.

Okay, have a seat. I'll elaborate and lay out the whole story as I see it:

A very strong driver and motivator for people in open source is the well known "scratch your own itch", which also boils down to: if *nobody else* is scratching that itch - and it is annoying enough - I can do it. It is also very well known in open source (and elsewhere) that if someone else does the job, you don't have to do it. (No terribly surprising but I feel I need to spell it out clearly.)

How does this affect the reality of an open source project? It makes people follow this general pattern:

1 - if the project works fine and the products work fine, you're happy

2 - you find a problem, you submit a bug report or complain and hope that it
gets fixed soon. If it does, or you find a work-around, you're happy

3 - if the above steps weren't good enough, you consider actually debugging and working on a fix yourself. If the language/environment the project is using makes you feel comfortable enough. If it doesn't, you're back to mostly waiting and asking the project what else you can do to help.

4 - you debug and ideally end up submitting a patch to the project

5 - if the patch and your responses ot the patch were fine, the patch gets merged

From the project's point of view as well as the user's point of view, users should stay on level 1 or at worst level 2 in this table. The better the project works, the more users stay there. The fewer users that have to go down to 3 or more, the better for everyone involved.

It doesn't matter if that maintenance is done by a single person or an army of thousands. To the end user the satisfaction is independent of that number.

But okay, that's right now when the project runs fine and everyone is merry. What happens when things go sour. If a project has 51% of all commits or 51% of all lines of codes written by one or two persons (or however you want to calculate the bus factor).

Suddenly people will move along those "satisfaction levels" to a much higher degree and people will suddenly start to actually have to roll up their sleeves to do work. Then what is important for them to successfully do so? A working process (so that changes can be received and handled). Quality source code that isn't too hard to modify. Documentation that helps you understand how things work and what to change. Tests for making sure your changes don't cause too many regressions. Quite likely also you want a communication channel. Etc. All of that should work totally independent of the bus factor. If those things don't work, they are independent issues for the project and are failures that are unrelated to the bus factor.

We simply cannot know who would step up to do the work if the fearless leaders who did the 51% vanished. Since when people didn't have to do it before, they avoided it.

All the availabe tools that determine this factor only run on code and check for commits or code churn etc.
True, but we don't have to limit ourselves to stuff that can be determined with automated tools. I do think that tools can help determine a likely value in this case.
Well, this number is really impossible to figure out without tools and I don't see how tools can take "general knowledge" into account, or "this person answers a lot of email on the list", or this person has 48k in reputation on stack overflow already for responding to questions about the project.

So bus factor is about code(?) (amount/changes), which may or may not be a good indicator of who knows what about the code. Those who author and commit changes probably have a good idea but a real problem is that you can't reverse that view and say that just because you *didn't* commit or change something, you don't know.

We can't prove or assume lack of knowledge or interest by the lack of commits or changes.

I like curl & often use it myself. So let's be specific: If you died (please don't any time soon), could someone just pick up & continue? Who?
curl is soon 20 years old and boasts about 22k commits. I'm the author of about 57% of them, and the second-most committer (who's not involved anymore) has about 12%. Two committers at 15300 commits. If we for simplicity calculate bus factor based on commit numbers, we'd need 8580 commits from others and I should stop completely to reach bus factor >2 (when the 2 top committers have less than 50% of the commits), which at the current commit rate equals in about 5 years. So even when someone new comes into the project, they have a really hard time to significantly change the bus factor... Especially since my personal commit rate have not gone down (much).

We're approaching 1600 individually named contributors thanked in the project and every release we do (we ship one every 8 weeks) has around 40 contributors, out of which typically around half are newcomers. The long tail is very long and the amount of drive-by just-once contributors is high.

When we ask our users "why don't you contribute (more) to the project?" (which we do annually) what do they answer? They say its because 1) everything works, 2) I don't have time 3) things get fixed fast enough 4) I don't know the programming language 5) I don't have the energy.

First as the 6th answer (at 5% 2017) comes "other" where some people actually say they wouldn't know where to start and so on.

All of this taken together: no signs of us *suffering* from having a low bus factor. Lots of signs that people can do things when they want to if I don't do it. Lots of signs that the code and concepts are understood.

Lots of signs that bus factor is irrelevant here.

Do I *know* who would pick up the project and move on if I die today? No. We're a 100% volunteer-driven project. We're one of the world's most widely used software components (easily more than three billion instances and counting) but we don't know who'll be around tomorrow to work on it. I can't know because that's not how the project works.

Given the extremly wide use of our stuff, given the huge contributor base, given the vast amounts of documentation and tests I think it'll work out.

Now of course the "best practices" need to be generic but I really don't think our project is that unique and special in this regard. I have my own unique and special insight into this project and that's why I use it as an example here, but I'm convinced that there are many more in similar situations.

Just because you have a large bus factor doesn't necessarily make the project a better place to ask questions. We've seen projects in the past where N persons involved are all from the same company and when that company removes its support for that project those people all go away. High bus factor, no people to ask.

(Finally, let me just add that I would of course *love* to have many more committers and contributors, and I think we would be a better project if we did. But that's a separate issue.)

--

/ daniel.haxx.se


Re: documentation_roadmap

David A. Wheeler
 

So for silver level, a project MUST have a "roadmap".

Does the project also have to actually implement or work on any of the items
in the roadmap? If so, to what degree? If not, what's the purpose of this
criteria?
Text:
The project MUST have a documented roadmap that describes what the project intends to do and not do for at least the next year. [documentation_roadmap]

We tried to define the purpose of this criterion in the details:
Details: The project might not achieve the roadmap, and that's fine; the purpose of the roadmap is to help potential users and constributors understand the intended direction of the project. It need not be detailed.

Some projects don't plan to make any changes; some plan to make modest changes; some plan to rewrite everything & the API is going out the window. It's helpful for users to know where the project intends to go. Not everything goes as planned, but at least the user has an inkling.

Does that help?

It might be useful to look at the BadgeApp's roadmap:
https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/roadmap.md

You'll notice that at this point we do *not* have grand plans for the BadgeApp - we wanted to add internationalization & higher levels, and did that. At this point we're expecting to do more refinements than big plans, and that's fine... just let users know that.

--- David A. Wheeler


Re: I claim "bus factor" is mostly useless

David A. Wheeler
 

Daniel Stenberg:
Since you've now added "bus factor" as a criteria...
First - just to put it one place, let met copy here the criteria text. This is SHOULD at silver, MUST at gold (it is *not* at passing). The text at silver:
The project SHOULD have a "bus factor" of 2 or more. [bus_factor]
Details: A "bus factor" (aka "truck factor") is the minimum number of project members that have to suddenly disappear from a project ("hit by a bus") before the project stalls due to lack of knowledgeable or competent personnel. The truck-factor tool can estimate this for projects on GitHub. For more information, see Assessing the Bus Factor of Git Repositories by Cosentino et al.

can someone please
explain how this is valuable to users of open source projects?
Absolutely!

It's valuable for users to know that even if the current lead died, the project could simply continue. The basic issue here is that we're all mortal (vulnerable to being "hit by a bus"). Even if the project is popular, that doesn't mean that it can be easily continued if the lead disappears.

All the availabe tools that determine this factor only run on code and check
for commits or code churn etc. They can't tell the general "knowledge level"
or how many people "understand" the code or particular areas? How many
people read and deal with the code without sending back patches?
True, but we don't have to limit ourselves to stuff that can be determined with automated tools. I do think that tools can help determine a likely value in this case.

For a documented, proven, old, established open source project with an
active maintainer, it is *easy* to have a bus factor that is less than two when
checked by scripts like you encourage in the criteria, but yet if said person
would be run over by a bus there's very little indications that the project
would stall or die because of that.
I like curl & often use it myself. So let's be specific: If you died (please don't any time soon), could someone just pick up & continue? Who?

The bus factor could perhaps be relevant if there were no docs, if the code
was poorly written, uncommented or barely tested. But all those are *also*
criteria...
I've had to pick up projects I've never seen before. It's absolutely true that docs, well-written code, and good tests are a big help. But having someone to ask, and work with at the beginning, is also a *huge* help.

I have plans to live on for a while longer (good plan, right?). But if something happened to me, I know that Dan Kohn & Jason Dossett are well-versed in the code & have all the necessary commit rights on this project.

So then. I hold up my finger and sense that more at least a few more people
than me know my project. Is that a met criteria?
I hope you'll stick around on this earth a while longer :-).

But if you suddenly died or were incapacitated, could someone else carry on? Who? Who knows the code well enough, and has the necessary rights, to continue? If you can identify at least one other person, then it's met.

--- David A. Wheeler


documentation_roadmap

Daniel Stenberg
 

Hi,

So for silver level, a project MUST have a "roadmap".

Does the project also have to actually implement or work on any of the items in the roadmap? If so, to what degree? If not, what's the purpose of this criteria?

I think this is a bad criteria.

--

/ daniel.haxx.se


I claim "bus factor" is mostly useless

Daniel Stenberg
 

Hi,

Since you've now added "bus factor" as a criteria, can someone please explain how this is valuable to users of open source projects?

All the availabe tools that determine this factor only run on code and check for commits or code churn etc. They can't tell the general "knowledge level" or how many people "understand" the code or particular areas? How many people read and deal with the code without sending back patches?

For a documented, proven, old, established open source project with an active maintainer, it is *easy* to have a bus factor that is less than two when checked by scripts like you encourage in the criteria, but yet if said person would be run over by a bus there's very little indications that the project would stall or die because of that.

The bus factor could perhaps be relevant if there were no docs, if the code was poorly written, uncommented or barely tested. But all those are *also* criteria...

So then. I hold up my finger and sense that more at least a few more people than me know my project. Is that a met criteria?

--

/ daniel.haxx.se


Formally announcing: silver/gold levels & internationalization

David A. Wheeler
 

All:

Nicko van Someren has written a very nice blog post about the recent enhancements to the Best Practice Badge program, in particular the higher silver/gold levels & our new support for internationalization: https://www.coreinfrastructure.org/news/blogs/2017/06/cii-best-practices-badge-program-announces-higher-level-certification-and

Very soon Marcus Streets will be giving a talk in Beijing about the CII and will be talking about the internationalized version of the application & other related materials.

I want to *SINCERELY* thank everyone here for all your help in making this possible. I especially want to give a shout out to our translators - you're amazing. The translators are: Yannick Moy, Wanganyu (Andrew Wang), Georg Link, Alexander "Alex" Meik Mikulla, Andy Distler, Takashi Kunai, Hiroyuki Fukuchi (HONSHA), Mieko Sato, Kitsune Ral (my sincere apologies for any omissions or incorrect names!).

The BadgeApp itself now meets the "silver" criteria, and we're shooting for gold.

--- David A. Wheeler


Re: Projects that received badges (monthly summary)

David A. Wheeler
 

Badgeapp:
This is an automated monthly status report of the best practices badge application covering the month 2017-05.
Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.
All:

This was the first completely-automatic monthly report from the badge application. I think it worked pretty well, and I think monthly status reports shouldn't be overwhelming. You'll notice that things are progressing nicely: Projects continue to start, continue to make progress, and a few manage to get a badge.

As always, you can see many more statistic here:
https://bestpractices.coreinfrastructure.org/project_stats

--- David A. Wheeler


Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2017-05.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2017-04-292017-05-30
Total Projects744820
Projects 25%+277306
Projects 50%+224250
Projects 75%+177195
Projects passing7682

Here are the projects that first achieved a passing badge in 2017-05:

  1. Hyperledger Fabric at 2017-05-11 11:43:38 UTC
  2. aiengine at 2017-05-12 20:18:29 UTC
  3. The System Integrity Management Project (SIMP) at 2017-05-18 16:34:35 UTC
  4. nvm at 2017-05-22 20:06:10 UTC
  5. Hyperledger Sawtooth Distributed Ledger at 2017-05-23 19:00:58 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!


Internationalization & localization

David A. Wheeler
 

We are basically done internationalizing the BadgeApp.  It was a lot of work, but it means that people will be able to (eventually) see all the criteria text – and the rest of the system – in their preferred locale.  If we missed something (probable), pull requests are welcome.  The *hope* is that this will lead to more participation.

 

We now need it translated.  It currently has 635 segments that need translating.

 

We currently have native speakers working on French (fr), German (de), and Simplified Chinese (zh-CN).  We’ve reserved Japanese (ja).  If you’re a native speaker of any of those, please volunteer – with more than one person it doesn’t take long.

 

It’s not immediately obvious how to invoke this (though logged-in users can edit their profiles to change their default locale).  We don’t want to make it more obvious until we have at least one other locale’s translations done.  But it’s basically triggered via the URL, just add the locale at the beginning of the path (this even works at the top).  E.G.:

https://bestpractices.coreinfrastructure.org/zh-CN/projects/

 

--- David A. Wheeler

 


Higher criteria levels implemented. Names: passing+1 => silver, passing+2 => gold

David A. Wheeler
 

We’ve implemented the higher criteria in the BadgeApp, and given the higher levels official names.  The official name for “passing+1” is “silver”, and “passing+2” is “gold”.  That means that our 3 (current) levels are “passing”, “silver” and “gold”.

 

I’d earlier asked about names, but this is fundamentally picking the color of the bike shed, and I really don’t want to waste a lot of group time on that.  The real goal is, therefore, simply to “find something reasonable”.  I think these are reasonable names.  Rationale:

1. A “metal” theme is consistent with others’ level naming schemes (e.g., Olympic medals, LEED).

2. By using “silver” and “gold” we can later add a higher “platinum” level, so this is more future-proof.

3. Historically silver & gold have been used for currencies in many places around the world, so I expect that in many locales they will have an implied meaning of “valuable”.

4. By using “passing” (not “bronze”) for the first level we keep our current terminology & avoid suggesting that the first level is not very valuable.  In at least the US, “bronze” can imply “inferior”.  We want to avoid that!  Getting “passing” turns out to be rather challenging, and only about 10% of pursuing projects manage to get “passing”… so getting “passing” is certainly *not* inferior!

 

You can see the higher-level criteria by appending “/1” (silver criteria) or “/2” (gold criteria) to the project entry.  For example:

  https://bestpractices.coreinfrastructure.org/projects/1/1

  https://bestpractices.coreinfrastructure.org/projects/1/2

 

We’re intentionally not making this obvious yet in the UI, but it’s there!  Once we’re a little more satisfied, we’ll make it more obvious to select.  The current “future” criteria will probably disappear, because they’re now in higher-level criteria.

 

--- David A. Wheeler

 


Beginnings of internationalization now on production site

David A. Wheeler
 

FYI, the BadgeApp production site now has the beginnings of internationalization & localization.  We’ve begun with two locales besides English: French (fr) and Simplified Chinese (zh-CN).  It’s still early, but you can now see it live.

 

If anyone who is a *native* speaker in another locale would be willing to assist, please let me know.  Translation.io makes it relatively easy to edit.  You just use a web browser, and they provide “starter suggestions” based on past translations & Google translate.

 

URLs select the locale to display, and on login users are transitioned to their preferred locale (unless they’ve already selected one via the URL).  At the top level URLs are of the form “?locale=NAME”, otherwise the URLs are of the form “https://bestpractices.coreinfrastructure.org/LOCALE/...”.  These are fairly common conventions for locale selection.  E.G.:

* https://bestpractices.coreinfrastructure.org/?locale=zh-CN

* https://bestpractices.coreinfrastructure.org/zh-CN/project_stats

* https://bestpractices.coreinfrastructure.org/?locale=fr

* https://bestpractices.coreinfrastructure.org/fr/project_stats

 

It’s incomplete.  Internationalization involves a lot of little boring changes, so it’s taken a little time.  The main form for entering project data hasn’t been internationalized yet, and some email doesn’t use the correct locale yet.  Those are in progress.

 

My special & sincere thanks to Wang Anyu (locale zh-CN) and Yannick Moy (locale fr), who have been doing the translations.  Google translate & I did some of the initial French work, and all speakers of French are glad I’m not doing that any more J.

 

At this time the plan is leave project *justifications* (details) in English.  One problem is that reviewing justifications in arbitrary languages is, well, complicated.  But this *does* mean that a potential user of a project can see a project’s status for every criterion, in the preferred language of that user.  My hope is that this will encourage potential users to use the results of well-run projects.

 

--- David A. Wheeler

 


Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2017-04.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2017-03-302017-04-29
Total Projects685744
Projects 25%+260277
Projects 50%+213224
Projects 75%+171177
Projects passing7176

Here are the projects that first achieved a passing badge in 2017-04:

  1. Xen Project at 2017-04-07 12:27:27 UTC
  2. doctest at 2017-04-12 12:00:12 UTC
  3. Chamilo at 2017-04-12 19:12:36 UTC
  4. App Store for Nextcloud at 2017-04-16 18:57:21 UTC
  5. The new pugachu website! at 2017-04-22 18:09:51 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!


Re: BadgeApp website internationalization

Mark Rader
 

David

You may also want to ask OWASP/ZAP what they use since they extensively internationalize. 

Mark

On Fri, May 5, 2017 at 1:04 PM, Wheeler, David A <dwheeler@...> wrote:
Dan Kohn:
> It may be worth considering this service, which is free for open source projects, if we invest further in i18n.
> https://translation.io/

Great idea.  I've requested an account.

We've often considered internationalization before, but Nicko recently asked us to actually add internationalization.

Machine translation isn't great, but it has gotten better over the years.  If we're going to support some locale X, I think it'd be useful to create machine translation as a first pass, include it in the distribution, and then have a human fix them over time.  That gives us an incremental approach, and where it makes sense I prefer incremental approaches over a "big bang" approach ("big bang" approaches have the risk of never finishing).

--- David A. Wheeler

_______________________________________________
CII-badges mailing list
CII-badges@lists.coreinfrastructure.org
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges


Re: BadgeApp website internationalization

David A. Wheeler
 

Dan Kohn:
It may be worth considering this service, which is free for open source projects, if we invest further in i18n.
https://translation.io/
Great idea. I've requested an account.

We've often considered internationalization before, but Nicko recently asked us to actually add internationalization.

Machine translation isn't great, but it has gotten better over the years. If we're going to support some locale X, I think it'd be useful to create machine translation as a first pass, include it in the distribution, and then have a human fix them over time. That gives us an incremental approach, and where it makes sense I prefer incremental approaches over a "big bang" approach ("big bang" approaches have the risk of never finishing).

--- David A. Wheeler


Re: BadgeApp website internationalization

Dan Kohn
 

It may be worth considering this service, which is free for open source projects, if we invest further in i18n.


On Fri, May 5, 2017 at 1:00 PM, Wheeler, David A <dwheeler@...> wrote:

We’ve made a first step towards internationalizing the BadgeApp application on the “master” git branch.

 

We have a volunteer for zh (Chinese).  If anyone else would be willing to help localize, that’d be great… please let me know what locale.  There’s a start on ‘fr’ (French), if someone who *actually* knows French could help that’d be great (for example).

 

For supported locales, you can request seeing the locale just by adding the locale at the beginning of the path.  E.g., for “fr” (French):

  https://master.bestpractices.coreinfrastructure.org/fr

  https://master.bestpractices.coreinfrastructure.org/fr/login

 

Only a few pages support internationalization, only a few locales are allowed right now (en, fr, zh), and we don’t have *good* translations yet (there are a few stub “fr” pages provided by Google Translate).  We haven’t yet implemented, in particular, internationalizing the criteria text.  It’s all in progress.

 

This is only for *presenting* the BadgeApp text.  When people type in justifications, that’s a different story.  :-).  That said, it’s possible to write text that is easier for a machine to translate, and that may be the best recommendation.

 

--- David A. Wheeler

 


_______________________________________________
CII-badges mailing list
CII-badges@lists.coreinfrastructure.org
https://lists.coreinfrastructure.org/mailman/listinfo/cii-badges




--
Dan Kohn <mailto:dan@...>
Executive Director, Cloud Native Computing Foundation <https://cncf.io/>
tel:+1-415-233-1000


BadgeApp website internationalization

David A. Wheeler
 

We’ve made a first step towards internationalizing the BadgeApp application on the “master” git branch.

 

We have a volunteer for zh (Chinese).  If anyone else would be willing to help localize, that’d be great… please let me know what locale.  There’s a start on ‘fr’ (French), if someone who *actually* knows French could help that’d be great (for example).

 

For supported locales, you can request seeing the locale just by adding the locale at the beginning of the path.  E.g., for “fr” (French):

  https://master.bestpractices.coreinfrastructure.org/fr

  https://master.bestpractices.coreinfrastructure.org/fr/login

 

Only a few pages support internationalization, only a few locales are allowed right now (en, fr, zh), and we don’t have *good* translations yet (there are a few stub “fr” pages provided by Google Translate).  We haven’t yet implemented, in particular, internationalizing the criteria text.  It’s all in progress.

 

This is only for *presenting* the BadgeApp text.  When people type in justifications, that’s a different story.  :-).  That said, it’s possible to write text that is easier for a machine to translate, and that may be the best recommendation.

 

--- David A. Wheeler

 


Starting to implement higher levels (#740) & internationalization (#739)

David A. Wheeler
 

We’ve gotten feedback on the proposed criteria for higher levels, and tried to respond where we could (thanks to everyone!):

  https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/other.md

 

The plan is now to *implement* this in the BadgeApp, which is issue #740:

  https://github.com/linuxfoundation/cii-best-practices-badge/issues/740

 

The current plan is to have completely different views for each level; that’s easier to understand & easier to implement.  E.g., /projects/1?level=0 would should the current “passing” level, while /projects/1?level=1 would show “passing+1” level.  The LF will have to bikeshed what they want “passing+1” actually named, but I’m expecting some sort of metal theme (silver/gold, gold/platinum, or whatever).

 

We also intend to internationalize the software (so that others can localize it), per #739:

  https://github.com/linuxfoundation/cii-best-practices-badge/issues/739

 

This won’t happen instantly, but I wanted to make sure everyone was informed!

 

--- David A. Wheeler

 

 


Re: Projects that received badges (monthly summary)

David A. Wheeler
 

Subscribers here have hopefully noticed a new kind of email, with the subject “[CII-badges] Projects that received badges (monthly summary)”.

 

This is a new feature.  The plan is that the BadgeApp will send an email once a month to this mailing list.  This email will provide some basic information about the past month, e.g., the projects that got a badge that month & some overall statistics.  Since there are many OSS projects, you shouldn’t expect to recognize most of the ones getting badges, but hopefully you’ll recognize a few (e.g., Xen got a badge in April – congrats!!!).  If a project got a badge but seems dubious for some reason, please let us know.  We do check passing projects, but an advantage of this monthly email is that it alerts more people about passing projects (which they can then review and challenge).  In any case, a monthly email should help you get a sense of what’s going on, with no effort on your part.

 

My *hope* is that emails that only show up once a month aren’t bothersome, especially since they’re simply an overall summary of key activity from that month.  All of us are busy, so I really don’t want to do anything that’s overwhelming to people.  Only a small percentage of projects are passing, but even if there’s a lot of growth, a single email (even if it’s long) should be no big deal.

 

I don’t want to overwhelm anyone, so I think we should keep it to this kind of information and (monthly) rate.  If you want more details about the status of badges, I suggest visiting the following:

1. Detailed statistics: https://bestpractices.coreinfrastructure.org/project_stats

2. The BadgeApp RSS feed:  https://bestpractices.coreinfrastructure.org/feed

3. Overview of projects (you can search, sort, etc.): https://bestpractices.coreinfrastructure.org/projects

 

If there are big objections, please let me know.  We haven’t made this actually report monthly (I wanted to make sure it worked first!), but that is the plan.

 

--- David A. Wheeler

 

 

From: cii-badges-bounces@... [mailto:cii-badges-bounces@...] On Behalf Of badgeapp@...
Sent: Tuesday, May 02, 2017 4:24 PM
To: cii-badges@...
Subject: [CII-badges] Projects that received badges (monthly summary)

 

This is an automated monthly status report of the best practices badge application covering the month 2017-04.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates

2017-03-30

2017-04-29

Total Projects

685

744

Projects 25%+

260

277

Projects 50%+

213

224

Projects 75%+

171

177

Projects passing

71

76

Here are the projects that first achieved a passing badge in 2017-04:

  1. Xen Project at 2017-04-07 12:27:27 UTC
  2. doctest at 2017-04-12 12:00:12 UTC
  3. Chamilo at 2017-04-12 19:12:36 UTC
  4. App Store for Nextcloud at 2017-04-16 18:57:21 UTC
  5. The new pugachu website! at 2017-04-22 18:09:51 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!


Projects that received badges (monthly summary)

badgeapp@...
 

This is an automated monthly status report of the best practices badge application covering the month 2017-04.

Here are some selected statistics for most recent completed month, preceded by the same statistics for the end of the month before that.

Ending dates2017-03-302017-04-29
Total Projects685744
Projects 25%+260277
Projects 50%+213224
Projects 75%+171177
Projects passing7176

Here are the projects that first achieved a passing badge in 2017-04:

  1. Xen Project at 2017-04-07 12:27:27 UTC
  2. doctest at 2017-04-12 12:00:12 UTC
  3. Chamilo at 2017-04-12 19:12:36 UTC
  4. App Store for Nextcloud at 2017-04-16 18:57:21 UTC
  5. The new pugachu website! at 2017-04-22 18:09:51 UTC

We congratulate them all!

Do you know a project that doesn't have a badge yet? Please suggest to them that they get a badge now!


How to disable emailed reminders with the mailing list password

David A. Wheeler
 

All:

 

FYI:  This mailing list is managed by the Linux Foundation using mailman.  By default, mailman sends a reminder message every month that includes your mailing list password (unique to each user and each list).  To our very NON-delight, that means a password is sent in the clear every month :-(.

 

The LF is well aware that the password security on mailman mailing lists is terrible.  However, the LF can't switch to Google Groups because it is inaccessible in China.  There are plans to implement better security for all its mailing lists, and that should solve the problem.  However, I don’t know when that will happen.

 

What you *can* do right now, if you’d like, is disable the monthly reminder. Go to:

  https://lists.coreinfrastructure.org/mailman/options/cii-badges

Log in, and go to “Get password reminder email for this list?”.  Select “no”, and push the button at the bottom “Submit my changes”.  Done!

 

In many cases email is transferred using an encrypted channel (TLS), which at least protects the email in motion (though not at rest).  I don’t know for certain if that’s true in this case; if someone can confirm or deny, that’d be great.  Password reset emails from the BadgeApp itself *are* encrypted in motion, when we can manage it, but that’s separate from this cii-badges mailing list.

 

I hope that helps…!

 

--- David A. Wheeler

 

261 - 280 of 672