Besides, I would add that even for dependencies that are active, or dormant but responsive, users might still be at risk if everything depends on a single maintainer, who could go missing at any time. This is a common risk in open source software, close to the famous “bus factor” problem, which I tried to quantify more than 6 years ago,¹ using data that were already coming at the time from Andrew Nesbitt.

We keep reminding users that open source software comes with no guarantee, and in particular no guarantee of future maintenance, so they have no right to complain if they don’t support the project, financially or otherwise. But that does not mean that all open source dependencies carry the same risks. Some of them are effectively “dead” or insufficiently maintained to be safe to use, but others, on the contrary, are well maintained, and perfectly safe to use. So it would be nice if there was a way for projects to signal their maintenance status.

Of course, it is not as easy as declaring “this project is maintained”, as this could very well be true when the declaration is committed to the repository, but it might no longer be true two years later when a problem arises and requires attention.

So here is my proposal, inspired by several sources, including the recent work on adding an x-maintenance-intent field to opam (the OCaml package manager) metadata, as well as the ongoing work of my postdoc Antonin Delpeuch on helping projects make their governance explicit through a GOVERNANCE.md file.

A MAINTENANCE.md file

This would be a file that could be added to the root of a repository (like the current practice for standard files such as README.md, CONTRIBUTING.md, CODE_OF_CONDUCT.md, GOVERNANCE.md, SECURITY.md, etc.)² that would contain information about the maintenance intent and status of the project. Here are the sections that I would expect to find in such a file (and we could “normalize” them so that tools can consume them³ and display them in package registries, for instance):

• Maintenance intent: what types of maintenance activities the project intends to perform (e.g., “the project is actively developed and new features are regularly added”, “the project is in maintenance mode and only bug fixes and security patches are provided”, “the project is mostly dormant but the maintainers will respond to vulnerability reports and critical bug fixes”, or “the project was developed as a fun hobby project and there is no intent to support users or any commitment to fix security issues”).

• Active versions: which versions of the project are actively maintained (e.g., “only the latest major version is maintained”, “versions 2 and 3 are maintained, but 2 only receives security patches”).

• Maintenance team: who is responsible for maintenance activities. In particular, who has commit rights, who currently handles the releases, who else has rights to publish new versions to the package registry and could step in if the main maintainer goes missing, etc.

• Maintenance team check-in: as part of the above section, a statement about how often each maintainer is expected to check in to show that they are still active and reachable. This could be done by committing to the repository, or even by committing to the MAINTENANCE.md file itself if no other activity was needed. The commit to the MAINTENANCE.md file could also be used to record the last time the team member checked that they still had access to the package registry. We could also invent a new badge that would show when this author last committed to the repository. This information is particularly important because it would allow us to distinguish between “dormant but responsive” and “dead” dependencies (that Andrew Nesbitt had to classify as “unknown” in his analysis).

• How to help: if the project accepts help, for instance, in the form of funding (and what kind of additional maintenance activities this may guarantee), or in the form of engineering effort (including looking for new maintainers). Of course, after the event-stream and xz incidents, one might be wary of accepting new maintainers and some could argue that explicitly asking for help can even make projects a target of social engineering attacks, but on the other hand, it may be better to be transparent about this need and look for new maintainers early, rather than wait for maintainers to burn out and have to appoint new ones in a hurry. In particular, this declaration does not mean that the project has to appoint anyone who proposes to help.

Note that the goal of this new file is not to repeat or replace the information that can already be found in other files, such as GOVERNANCE.md for how new maintainers are appointed, or SECURITY.md for how to report security vulnerabilities. Any information that is already present elsewhere can be simply linked from the MAINTENANCE.md file.

All in all, the file could look like this:

# Maintenance intent

Project X is currently in maintenance mode, and only bug fixes and security
patches are provided.

## Active versions

The latest major version (3.x) receives regular bug fixes and security 
patches. Version 2.x only receives security patches, and version 1.x is no
longer maintained.

## Maintenance team

- Alice (@alice):
  - Commit rights, release manager, has access to the package registry.
  - Checks in at least once every 3 months.
  - Last check-in to `MAINTENANCE.md`: 2026-05-01 (confirmed access to the package registry).
  - Last commit to the repository: \
    ![check-in badge](https://img.shields.io/badge/does-not-exists-yet?project=X&who=alice&freq=3m)
- Bob (@bob):
  - Commit rights, has access to the package registry.
  - Checks in at least once every 6 months.
  - Last check-in to `MAINTENANCE.md`: 2026-01-15 (confirmed access to the package registry).
  - Last commit to the repository: \
    ![check-in badge](https://img.shields.io/badge/does-not-exists-yet?project=X&who=bob&freq=6m)
- Carol (@carol):
  - Commit rights.
  - Checks in at least once every 6 months.
  - Last check-in to `MAINTENANCE.md`: 2024-09-23.
  - Last commit to the repository: \
    ![check-in badge](https://img.shields.io/badge/does-not-exists-yet?project=X&who=carol&freq=6m)

## How to help

Maintainers are not currently accepting financial support and do not have
the bandwidth to review new feature proposals. Getting new maintainers on
board could help make the project more active and accept new features again.

In the example above, Carol has not checked in to the MAINTENANCE.md file for more than 6 months, but the badge could still show that her last commit to the repository was within the last six months.

What do you think?

My goal with this proposal is to come up with a methodology that would be lightweight for maintainers to implement, but would also help with transparency toward users about a project’s status and automatically signal when there is an issue with maintainers’ availability. I am particularly interested in hearing from maintainers whether this is something they would be willing to adopt.

In particular, I believe that we should stop reasoning that, just because an open source package happens to have many dependents, the author should have a particular responsibility toward its users. If there are good mechanisms to communicate maintenance intent and status, then users can make informed decisions about which dependencies to use, and maintainers can also explain under what conditions they are willing to provide support. Authors who created packages as just a hobby can be transparent about not wanting to support users, and users are free to fork the project and maintain it themselves if they are not satisfied with the level of maintenance provided by the original author.

This problem is often unavoidable because the available manpower to fix bugs and limitations rarely scales as fast as the manpower to report them. Therefore, the number of open bugs in the issue tracker of popular projects can end up growing and growing until a point where it becomes hard to manage.¹

The stale bot approach

To alleviate this problem, many open source projects are nowadays choosing to rely on “stale bots”, bots that automatically act on inactive issues (and pull requests), generally to close them. Wessel et al.² have done a preliminary study of projects that use the most well-known stale bot: https://github.com/apps/stale.

However, everyone that has spent time writing a careful bug report, only to see that it got no reply, but the one of the bot that closed it for being stale, can testify that this doesn’t feel like a great experience and doesn’t give much incentive to report the next bug you encounter. Open source maintainers are often aware of this: to illustrate, see this long discussion of nixpkgs maintainers and contributors about the introduction of a stale bot, or this blog post of the Gradle project to justify their use of a stale bot (which they link to in every message posted by the bot).

I think that there are many research opportunities to study stale bots usage beyond what Wessel et al.² did. Some research questions that come to mind:

1. In which context are stale bots introduced by project maintainers?
2. Are project maintainers satisfied with the stale bot solution?
3. How do issue reporters perceive the use of the stale bot?
4. What consequences does it have on the behavior of issue reporters? (Do they refrain from reporting new bugs they discover?)

To be addressed, these research questions would probably require a combination of quantitative and qualitative methods: mining software repositories, coding public discussions and blog posts, interviewing maintainers and issue reporters, econometrics methods to derive causality from quasi-experiments.

In the meantime, and without this evidence-based knowledge, as an open source maintainer, I am personally reluctant to introduce a stale bot to close our huge issue backlog in the Coq repository. Instead, I wish to explore alternative triaging approaches that scale.

Documenting known issues

Releasing software with known issues happens all the time. Some known issues are left unfixed because of lack of manpower to fix them and because they are not of top priority. Some known issues are left unfixed because fixing them is hard and designing a proper solution will take time. In both cases, it is perfectly acceptable to release software, but acknowledging and documenting known issues is always a good idea.

First, documenting known issues can avoid users spending time on things which do not work and getting frustrated. When there are known workarounds, documenting them will help users figure out how to proceed instead.

Second, keeping a list of known issues can also avoid getting duplicate reports when users encounter these issues. And when duplicate reports are created nonetheless, they can help maintainers figure out that this is really a duplicate and where the canonical issue is to be found.

For users to easily find out about known issues, they should be documented close to the feature they are a limitation of. And when they are introduced in a new release, they should appear in the release notes.

For issue reporters and maintainers to quickly find a known issue, an index of known issue can be a useful thing to have. But it is not a strict requirement if they can easily locate the documentation of the corresponding feature (and the known issues are easy to spot from there).

If documented known issues provide a link to the canonical discussion, this can also help potential contributors become active participants in the resolution.

Keeping the list of open issues focused

Accumulating a long list of open issues that are not actively worked on can be legitimately viewed as inefficient.

While closing issues which are not actively worked on with a stale bot risks burying them and leading to duplicate reports, closing inactive but documented known issues should not create such problems. Because they are documented, known issues are not just forgotten about. Ideally, the documentation even comes with a test case (within or separate from the documentation) that will help discover when they are accidentally closed or become irrelevant. Furthermore, if at any point, anyone wants to contribute to the discussion of the known issue, it is easy for them to do so if a link from the documentation to the canonical discussion is available.

Therefore, it seems reasonable to refine the stale bot approach into a novel stale known issue approach. This approach would roughly work in the following way:

1. When a bug or a limitation is reported, it should be confirmed (reproduced).
2. A confirmed bug or limitation which does not look like it will be fixed by the time of the next release should be documented as a known issue.
3. A documented known issue which is not receiving activity should be closed.
4. Any known issue receiving new activity (a new comment or a contributor self-assigning the issue) should be reopened (and reclosed if it becomes stale again).

The contributing documentation should direct potential contributors to the list of known issues, in addition to the list of open ones.

A bot and a clever use of labels or GitHub new projects can serve to implement and automate the above process.

Introducing this approach in a project with a big backlog

If we want to adopt this approach in the Coq project, the first thing we need to do is to handle the backlog of known, but undocumented issues.

Developers have expressed the need to document known issues several times in the past, so this objective is shared.³ What I’m not sure will be shared is the scope of known issues needing to be documented, but we can start with the ones that are consensual and work our way from there.

In PR #15102, I am introducing a special directive so that we can document (and highlight) known issues in the Coq reference manual. I am also experimenting with using a GitHub project to manage the list of known issues, those that need documentation and those that are documented. The project also provides a custom field to add a link from the issue to its documentation. In the future, we could add a column/status for the known issues that are documented and stale, and thus that could be (temporarily) closed.

In this market where trust is based on automatic proof checkers, we can imagine how disruptive a proof of False may be: someone who is able to make the checker believe that they can prove False can actually prove any theorem and therefore is able to claim payment for any awaiting conjecture. They can also produce programs that do not really meet the specifications they claim to meet.

Until we can have absolute certainty that a proof checker, such as the kernel of a proof assistant, does not make it possible to prove False,¹ we need to leave room for this possibility and take measures so that it does not break havoc.²

To prevent a large disruptive effect, we need to have counter-measures for when a proof of False is found, and as soon as we acknowledge this, it becomes clear that we need to incentivize people to prove False and to share their proofs, by paying them for such a proof³ (in order to trigger said counter-measures).

What would counter-measures be like?

The basic idea is rather simple: as soon as a proof of False has been found, freeze the entire market for the time it takes for the developers of the proof checker to release a new version where the bug has been fixed. Once such a version is released, check all existing proofs and put transactions that are linked to a proof that does not check anymore on hold. If a proof was relying on a lemma that has been invalidated, the proof (and the associated transaction) can still be saved by finding an alternative proof to the lemma. Alternatively, if a transaction is associated to a theorem whose negation happens to be provable, or if no valid proof can be found for a reasonable delay, revert the transaction.

This looks like transaction history rewriting, like the hard fork of Ethereum blockchain after the DAO event, but this is different because here the reverting of such transactions is part of the predefined crypto-currency protocol so there is no debating to do on the legitimacy of such an action.

How to make sure that people share their proof of False rather than using them to steal other people’s money?

All proofs are public and people may look at them carefully to see whether they look suspicious or not. If a proof looks suspicious, then the person who finds the proof suspicious can try to derive a proof of False from it, either by proving that the theorem that is proved is actually wrong, or by extracting the fallacious argument (hack exploiting a critical bug) from the proof and using it to prove False directly. Then the person gets the reward and the original author of the suspicious proof loses their own rewards. Given that this is bound to happen, the self-interest of the original author pushes them to share their proof of False directly.

Where does the money for paying proofs of False come from?

The first solution that comes to the mind is to create these rewards out of fin air. Unfortunately, sudden creation of money decreases the value of the currency for everyone, and thus each proof of False has a negative impact on the whole market. This impact is unpredictable.

Another solution is inspired by CDS (credit default swaps): people can bet that no proof of False will be found by buying these bonds. The bonds have a predictable growth rate. Whenever a proof of False is found, the bonds serve to pay the reward and thus some people lose money but the actual market is unaffected (the money to pay the CDS rent is created⁴ in a fully predictable way).

This form of self-insurance would moreover be a strong driver to get a more and more resilient proof checker.

We could discuss how these bonds would work in more details, although this is not the subject of this post. Bonds could be created at regular intervals and so the longer since the last proof of False, the bigger the reward is (and the less interesting not sharing a proof of False becomes). The rent for these bonds could slowly decrease over time to compensate for the creation of new bonds (but sufficiently slowly so that people are well compensated for their initial investment). At bond creation, there could be an auction to choose who gets to buy it first and at what price.

Note that this might not be completely sufficient to avoid a sudden bad impact of a proof of False on the market, because if people start to believe that there is no proof of False left to be found, then they can start to think that the (large) reward for such a proof is never going to be claimed, and thus that this represents an amount of money that is actually out of the currency system. If such a belief is then contradicted, this would still create a shock.

Limitations

A first, important, limitation is the strong link required between the proof market and the crypto-currency itself. This is not without reason though, as smart contracts (which are basically programs) based upon invalidated proofs that they meet certain specifications would need to be invalidated as well.

A second limitation is the uncertainty that this places upon any transaction in the system. If some transactions happen to be reverted, then the wallet that was used to send you money may not have had enough money to actually do so. Then you will lose whatever exceeding amount you have received from this wallet. If this means that you, in turn, would not have been able to realize some transactions you previously conducted, the recipient may lose part of their money as well…

This inherent risk to any transaction may be evaluated and taken into account. With a public transaction record, it is easy to compute a risk factor depending on the amount available in the payer’s wallet, the part of this money that comes directly from rewards in the proof market and how long the associated proofs have been there, and recursively the risk associated to each of the transactions the rest of the money comes from. If this risk is too high, it might be a reason to refuse a transaction. Otherwise, the associated risk might just be taken into account as a supplementary fee.

An alternative solution to both of these limitations is to make the proof market use its own reward tokens that can be converted into real digital coins only after some time has elapsed. Then only the internal transactions in the proof market can be reverted and there is no risk associated to transactions that take place outside of it. This supposes to define what delay would be sufficient to guarantee with near certainty that the proofs that were submitted are not suspicious.

Conclusion

We may legitimately ask whether this whole protocol is necessary. At the moment, proof checkers are not critical enough applications to be fully trustworthy in an adversarial context. They are very helpful to verify critical applications, but in this case the proof author is not trying to fool the checker, and the risk of accidentally exploiting a bug is much lower. We could wait until a proof checker is, itself, formally verified (a huge task but still bound to happen in the future). However, we would still be trusting a conjecture: that the underlying logic is consistent.⁵ That in itself may not be viewed as such a big problem, given that the whole field of cryptography, and therefore crypto-currencies as well, already depend on a conjecture.

I started contributing to Coq in 2015. This year, the Coq development team was organizing the first Coding Sprint (later renamed into the Coq Implementors Workshop) and was accepting pull requests on the GitHub repository to get patches from external contributors¹. Back in these days, almost none of the development was carried out through pull requests (I opened PR #68). Things have changed dramatically since then.

Pull requests are now used routinely to review other developers’ patches before integrating them; continuous integration was introduced to automatically test whether a proposed change breaks a number of tracked external developments (plugins and libraries)². These new processes have brought much stability to the software at the price of a reasonably small overhead. They have also demonstrated to be an excellent tool for sharing knowledge.

Meanwhile, bugs continued to be reported on Bugzilla, the bug tracker that was used since July 2007 (after a first migration from JitterBug). Bugzilla suffered from many drawbacks that were made all the more apparent when comparing to the much nicer experience we were having in pull request discussions on GitHub.

Simply setting e-mail notifications for new bug reports was a hard task: we had the mailing list coq-bugs-redist@lists.gforge.inria.fr which was connected to a Bugzilla account that was put in cc of all new bug reports. But to subscribe to this mailing list, you had to get moderator approval and, for some time, no one was administrating this mailing list anymore³.

More importantly, the lack of edition features, the difficulty to search an issue, the loading times, the intimidating UI had a (non-quantified but probably) significant impact on the developers, who tended to prefer slightly off-topic discussions and digressions in a pull request thread, rather than discussing each specific issue in a separate thread on Bugzilla.

In April 2017, I opened a wiki page to discuss the possible alternatives. Having a strong preference for gathering all our tools on GitHub, I documented this one (and no one really documented any other alternative, even if they existed).

In August, the Coq website was down for more than a week because of an over-reaction of the IT services to an alleged hacking of the bug tracker (in fact just a spam). This was a good opportunity to discuss once more a migration to GitHub issues (with hosting less dynamic, subject-to-attack, content as a nice benefit).

While I was initially proposing a transition during which we would be using both bug trackers in parallel, the need to keep bug numbers as much as possible was expressed and a script was found⁴ which was designed for that purpose.

The migration script

The migration script that was found is a Python script⁵ which takes an export from Bugzilla to XML as input and uses the GitHub API to create new issues for every bug reports. It inserts first the bug reports whose number it can keep⁶ and only when this is done it inserts bug reports that need to be renumbered.

Because issue numbers are attributed by GitHub at creation time and are not chosen by the issue author, it is not possible to skip some non-existent bug number. That’s why the script contained an initial check that the input bug numbers are contiguous. This was not the case for the Coq Bugzilla: many bugs had been deleted, especially in the early years. Thus, the first modification that I did to this script was to use postponed bug reports to fill the holes (missing bug numbers) to recreate continuity in the result. This worked because the number of pull requests was already higher than the number of holes.

To increase the predictability of new issue numbers, it was important that no issue or pull request be opened during the few hours that the migration took to complete. This was achieved thanks to the “cool-down” feature that GitHub provides.

We wanted to limit interaction permissions as much as possible during the migration, but removing contributors also meant losing the ability to assign issues to them. The solution that was found was to add all the people who had bug reports assigned to them to the External team of the Coq organization, then temporarily restrict the permissions of this team to “Read” (basically the same thing as anyone else given that this is a public repository).

Another critical issue with the script was that the GitHub API was limiting issue creation to 300, after what it refused any new posting for the next 30 minutes (not just through the API by the way, during my tests I was also prevented from manually posting comments during this delay). While I initially implemented a wait-period, this limitation was going to make the migration unbearably long. Fortunately, after reaching out to GitHub support, they explained that this limitation was imposed on any interaction that emitted notifications but that they also provided a beta API specifically dedicated to issue import that had many notable advantages, one of them being that new issues created through this API did not emit notifications, and thus were not submitted to the same rate limits.

There are many more advantages to this API: you can create at once an issue and many comments, set creation dates for each of them, assign someone, set a milestone and some labels, etc. Adapting the script to this API was easy: the main difference is that the API is asynchronous. To ensure that issue numbers are predictable, you must make it synchronous by sending GET requests to check whether an issue has been created before sending the next one. On the advice of GitHub support, I implemented a back-off approach: first wait one second before sending the GET request, if still pending wait for twice that time before sending another request, if still pending wait for twice the previous time, etc. The one-second delay meant that we could not import more than 3600 issues per hour in theory (in practice the migration almost took four hours, which indicates that many times it took more than one second to import an issue; I did not collect this information, unfortunately).

On the other hand, the API still has some limitations: you can’t recreate the complete history of closing/re-opening and assignments, the labels and the assignees are put at issue import time, whereas you can set the closing date. I regret not having set the updated_at field: I did not see what purpose it served: in fact it is useful when you sort issues by “Recently updated” (then GitHub displays the date of the last update).

This API does not allow you to choose the author of issues / comments either and requires API requests to be authenticated with a repository administrator API token. That’s why our bot account @coqbot appears as the author of all imported issues and comments.

Some other improvements of the script included saving a trace of imported bug reports with the Bugzilla / GitHub ID correspondence, and using this to safely recover from possible crashes, fixing most references to other bug reports, and some very Coq-specific stuff like not displaying comment authors for the first 1657 comments because these were imported from JitterBug to Bugzilla ten years ago and the migration attributed all the comments in a given bug report to the initial reporter.

The resulting script is, I believe, largely improved over the original one but also not as generic. If you wish to use it for your own migration, feel free to do so and don’t forget to remove the Coq-specific material first. If you want to share the result, especially if it is more generic, and thus a better basis for future users, I will be happy to add the link from this post.

Epilogue

The migration was formally approved at the Coq Working Group on Oct 3-4th, 2017, and was conducted right after the 8.7.0 release, on the morning of October 18th. It was preceded by a series of e-mails to announce it and the fact that both bug trackers (the old and the new one) would be read-only for the duration of the migration.

All the bugs with a number below 1154 had to be renumbered, you can find a nice correspondence table with a search bar here. All the other bugs kept their number.

While the migration went smoothly, only time will tell how effective the change was on the development organization. I plan to fiddle with the GitHub API some more to get interesting statistics of issue creation before and after the migration (with the cool advantage that dates have been preserved for bug reports from before the migration), how long it takes to solve a bug on average, the growth of unsolved issues, etc. If you know of some services or scripts that already provides such statistics, I would be happy to know about them.

In other news, Pierre Letouzey has migrated the Coq wiki to GitHub as well :) which means that the Coq website is fully static now.

Updates

• Pierre has reused the correspondence table to redirect previous Bugzilla URLs to new GitHub ones. For instance, https://coq.inria.fr/bugs/show_bug.cgi?id=2 now redirects to https://github.com/coq/coq/issues/1156 and https://coq.inria.fr/bugs/show_bug.cgi?id=1153 now redirects to https://github.com/coq/coq/issues/5970.
• Erik Martin-Dorel has adapted the script to the migration of issues from a GitHub repository to another one and has used it successfully to migrate the 101 issues from https://github.com/psteckler/ProofGeneral to https://github.com/ProofGeneral/PG. The new script is available at https://github.com/erikmd/github-issues-import-api-tools.

Like every programmer, I have known the Stack Overflow Q&A website for a long time now. For our community, it probably was one of the most important innovations of the recent years and it is now a routinely used tool. Have a question on programming? You google it, and you are most likely to find, among the first results, one or several questions on Stack Overflow with good answers to your problem. A little bit like when googling for a general notion, one of the first results should probably be a Wikipedia page.

This is one of the key aspects of the platform. Most of its traffic comes from search engines and, similarly to Wikipedia, most viewers are just that: viewers. The platform does not try and actually does not want to convert most of the viewers into users because they would not bring significant value (value for the platform being good questions and most importantly good answers). In that respect, it is taking a very different approach compared to all the “social” platforms that pop up these days, and in particular it is much different from Quora, a competitor Q&A platform, which used to require signing up just to view a single question (I never did; now it asks me to sign up to view a second question).

The second and the most known component of the platform formula is to award “reputation”. Users earn reputation points by asking good questions and giving good answers and being up-voted by other users. Reputation has an inherent value for some programmers because it can help demonstrate to future employers that you possess expert skills which have been recognized by others. The same teacher who encouraged the students in my class to create a blog and a LinkedIn account also told us about earning reputation on Stack Overflow.

Reputation is also key to getting more involved in the community itself as you can unlock new privileges when reaching certain levels. Thus, it acts as XP in video games and it actually helps gamifying the whole activity of helping each other out. And it acts as a filter. By not getting full access to the website features right from the start, new users are taken through a path which will teach them how to properly interact with it. Only with some reputation can you start up-voting, later you can start leaving comments, later still you can start down-voting.

The community self-moderates. Moderation is crowd-sourced, as people with enough moderation can vote to close down bad questions. The dreaded down-vote is one main source of moderation. And it is one of the barrier to overpass when you are a new user because you are most likely to not fully understand the website requirements¹. Thus people may down-vote your question. It can feel a bit harsh. But then if you are wise, you edit or delete your question and learn from the experience².

Questions should show research: don’t ask what is obvious. Questions are supposed to serve as a canonical documentation for later viewers: duplicates are banned. While it is generally not recommended to dig up an old thread on a traditional forum, it is very much encouraged to add your answer or a comment or your vote to an old question.

StackOverflow is organized with tags, and this is very useful given the number of questions the site receives. Given that I am not too much into mainstream technologies, I can reduce drastically the number of questions I see by following only the tags which I am interested in. This year, I started following the Coq tag for the same reason I follow the Coq-Club mailing list: to know what the questions of beginners are, and to learn from the answers that other people give.

The adventure of crowd-sourced documentation

In August of this year, Stack Overflow introduced Documentation in public beta. They got my attention immediately as I want to see how they can apply their reputation-based methodology to the more complicated problem of mass collaboration for writing. So far, only Wikipedia has developed a successful model for such mass collaboration.

Wikipedia’s model is based on a posteriori moderation: anyone can contribute anytime and their edit is live immediately, but some people and some bots are constantly reviewing recent changes and when changes do not respect the rules, or obviously decrease the page’s quality, they are reverted.

On the contrary, Stack Overflow’s model revolves around reputation-based a priori moderation. To start proposing changes to the documentation on one particular programming language, you will first have to demonstrate your skills by getting up-votes for an answer on this language.

According to Michael Nielsen in Reinventing discovery, the wiki-novel “A Million Penguins” was a failure mainly because moderation was done by a limited group of persons (students in fact) who could not keep up with all the contributions which arrived due to the publicity around the project. Stack Overflow does not do this mistake by having a large body of reviewers (anyone above a certain level of reputation). Although several positive reviews are necessary to approve an edit, there have still been problems with bad edits being approved too often³. While reverts (“rollbacks”) are possible, they are not supposed to be part of the standard workflow.

After being curious at the beginning and even contributing some documentation about Elm (a programming language I recently got interested in), I was a bit disappointed by the current result and stopped participating (this was also the beginning of my PhD so I had other topics with higher priority). Still, I think this will be interesting to see what this Documentation feature gives after a longer period of gradual improvements.

Update: As of August 2017, Stack Overflow has decided to shutdown the documentation, showing once again how hard organizing collaborative writing is.

The Stack Exchange galaxy

As Stack Overflow kicked off right from the start, new Q&A sites were added by the team so that other domains and other communities could benefit from the same reputation-based software. No site has ever reached the size of Stack Overflow, which is huge, but some of them have become pretty well-known on their own and all have an active community.

Nowadays, the process to create a new site is entirely community-driven. There is a series of steps to go through, and a special site dedicated to the creation of new sites: Area 51. This is somewhat comforting me a little from the fact that the software is not open source⁴. You cannot run your own instance, but at least if you gain enough momentum you can start a new site on a new topic.

Among the sites that were added lately (only one and a half year ago actually, so it is seven years younger than Stack Overflow) is a beta site on free and open source software. I registered four months ago to answer a question which was on the verge of being closed because people thought it was not answerable objectively. Since then, I’ve answered 46 more questions, always happy to spread the good word and to help out people who struggle to understand the complicated world of copyright and licenses (questions about licenses are what this site gets the most). This has also helped me gain reputation faster than on StackOverflow, and thus has allowed me to test and better understand the various priviledges and moderation tools so that I could write this blog post.

But it would be absolutely naive to be content with rejecting electronic voting on the whole because it is already in use everywhere: from professional elections, to associations… and even in certain political elections. Moreover, many politicians are now advocating for a general implementation of electronic voting, in particular with the aim of improving the rate of participation. We therefore shouldn’t refuse to look at and analyze the risks and benefits induced by this type of ballot. Or rather, we should say, these types of ballots. Electronic voting can be of two very different kinds: voting machines and Internet voting. We will deal with both but take care to distinguish between their issues.

Read the rest of this article on Kinea, the multilingual magazine where it was published.