Yes, it might not be an ungrounded idea that the top listed people
are busy. That is why having the MAINTAINERS.txt might not help you
contact people in the right areas. I've mapped out an idea in my talk
which would need implementation however.
We should tag the Drupal core files as well as modules with
meaningful tags based on their code. Then we should use more
meaningful tags on issues and can tag documentation pages. Now once we
have all these tags, we can aggregate them based on people! So the
people who are mentioned in commit messages for a file, contributed
to issues tagged similarly and edited doc pages tagged with certain
tags will get those tags on their user profile. So you could look up
not one but dozens of people working on field API, form API, views or
drupal commerce. This would let you find people who are probably less
busy but equally interested.
Finally, some modules do have the herders that you wish there were.
Views for example, has an issue queue squad helping maintainers to
clean up and respond to issues that do not require the maintainers.
Unfortunately the project page will only expose the committers, not
all the others who have herding permissions in the issue queues (and
therefore high likeliness they have insight into things regarding the
module). This would be a matter of having a front end UI for the data
which is already in the permissions assignments on the admin page of
the module.
I think this later simpler improvement and the former more complex
but very powerful improvement would let you find people related to
certain efforts, figure out structures, who's most active, etc.
without putting in lots of individual time to track this down. For the
former idea, all the data is there, you just need the time to dig. We
should eliminate the human effort there I think.
finding people to talk to
Yes, it might not be an ungrounded idea that the top listed people are busy. That is why having the MAINTAINERS.txt might not help you contact people in the right areas. I've mapped out an idea in my talk which would need implementation however.
We should tag the Drupal core files as well as modules with meaningful tags based on their code. Then we should use more meaningful tags on issues and can tag documentation pages. Now once we have all these tags, we can aggregate them based on people! So the people who are mentioned in commit messages for a file, contributed to issues tagged similarly and edited doc pages tagged with certain tags will get those tags on their user profile. So you could look up not one but dozens of people working on field API, form API, views or drupal commerce. This would let you find people who are probably less busy but equally interested.
Finally, some modules do have the herders that you wish there were. Views for example, has an issue queue squad helping maintainers to clean up and respond to issues that do not require the maintainers. Unfortunately the project page will only expose the committers, not all the others who have herding permissions in the issue queues (and therefore high likeliness they have insight into things regarding the module). This would be a matter of having a front end UI for the data which is already in the permissions assignments on the admin page of the module.
I think this later simpler improvement and the former more complex but very powerful improvement would let you find people related to certain efforts, figure out structures, who's most active, etc. without putting in lots of individual time to track this down. For the former idea, all the data is there, you just need the time to dig. We should eliminate the human effort there I think.