RFC: project maintainership

[jmitchell]

While discussing versioning strategy, @mashedcode recently pointed out many things remain undecided about this crate and asked for my thoughts. First, thank you all for being patient.

For several reasons I intend to officially step down as maintainer/owner:

1. I published it while I was learning Rust, and the only application I had in mind was constructing frequency distributions.

2. Now that I'm more comfortable with Rust I prefer directly using HashMap, BTreeMap, and sometimes arrays for frequency distributions. For this particular use case the HashMultiSet and the proposed BTreeMultiSet (#27) abstractions don't add much utility.

3. The semantics of multisets aside from tabulating frequencies are more nuanced than other std collections, e.g. there are multiple interpretations of union and intersection (see #22). I am not so familiar with the most practical use cases for each, and feel others who are can better judge what API design is least likely to violate the principle of least astonishment.

Open questions

1. Who should assume ownership of the repository and crate?
2. How shall I hand things off to the new maintainer(s)?

For those who don't know @mashedcode has had a commit-bit for about ~a year~ two years and has helpfully contributed to discussions. They have not been granted ownership status on crates.io.

@mashedcode, if you are interested in continuing to play a role do let us know. From what I've seen I think you'd make a great (co-)maintainer, but don't take that as pressure to sign up.

Likewise, several have taken an interest in improving and extending the crate. Pinging you all in order of PR appearance:

• @BartMassey
• @alexmocatta
• @HarrisonMc555
• @Ten0

Let's try to settle (1) before moving on to (2). The versioning discussion may overlap some with (2), but I'd like to leave room for the new maintainer(s) to address that. I'll let this rest for a week to see if a new maintainership team assembles. Thanks, all.

EDIT: I was curious about Cargo's versioning policy because I expect it will be relevant. According to the book:

While SemVer says there is no compatibility before 1.0.0, Cargo considers 0.x.y to be compatible with 0.x.z, where y ≥ z and x > 0.

[mashedcode]

Thank you @jmitchell for creating this crate in the first place.

I stumbled across this crate when I was writing a card game bot to learn rust. I simply used this crate to be able to hold multiple cards of the same kind. I'm actually not using this crate anymore either.

Therefore I also have a hard time relating to the actual use-cases of feature requests in various Issues and PRs. Which means I'd rather hand the maintainer work off to someone who preferably has multiple use-cases for this crate and therefore a real interest in it.

If there's no such person. I don't mind maintaining, making decisions, improving and merging open PRs simply so that PRs don't stay open forever and progress is done. Because I know how frustrating it is to open a PR to some crate just to never see any decision being made on your PR.

[Ten0]

the only application I had in mind was constructing frequency distributions.

Regarding the possible uses of the multiset, competitive programming is one, e.g. Codeforces Round #497 (Div. 2) - C. Reorder the Array where the solution would be extremely simple to express with a BTreeMultiset (at the time I had implemented it in C++):

    int n; cin >> n;
    vector<int> v(n);
    for(int i = 0; i < n; i++) cin >> v[i];

    multiset<int> s;
    for(int i = 0; i < n; i++) s.insert(v[i]);

    int count = 0;
    for(int i = 0; i < n; i++) {
        auto it = s.upper_bound(v[i]);
        if(it != s.end()) {
            count++;
            s.erase(it);
        }
    }

    cout << count << endl;