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 (BTreeMultiset + iter specializations #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 Implement union, intersection, union_counts, and intersection_counts #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;