Given the 5 vote limit, my own approach to voting for the council was pretty similar to the one that Eric describes: voting for what I considered to be a well-balanced council, rather than only considering the candidates in isolation from each other.
I think the Council needs at least a couple of folks with the “core dev for 10+ years” characteristic, simply because it’s a cat herding job, and in an online community like ours, it takes a long time to build up good mental models of other participants, such that you can make a decent attempt at correctly inferring all the things that they didn’t actually write down in their messages. Observing the core development process for that long also brings with it a host of past examples to compare new situations with, allowing some potential future missteps to be avoided.
However, I also think we’d be squandering an opportunity if we ended up with the Council as a whole being as demographically similar to each other as the criterion of “Python core developer for 10+ years” would currently imply, and instead hope we can achieve an outcome that better represents the complexity and diversity of the overall Python community (both in the sense of “the range of people using Python” and “the range of tasks that Python is being applied to”).
While there are limits to how representative a group of 5 people can be, we ideally want folks from multiple geographic regions, different personal & professional backgrounds, etc, as these are all things that can impact someone’s learning experiences, and hence the way they end up interacting with even something as seemingly abstract as a programming language. On that front, I think Eric’s list of characteristics is a nice way of thinking about some of the potential axes of difference worth considering.
I’ll also note that something we don’t know yet is the impact that the “only 5 votes” limit is going to have relative to pure approval voting. As discussed in Why limit to 5 votes?, my original concern with plain Approval voting was that we’d see experienced candidates getting a lot of “I trust them to keep doing what they’ve already been doing for years” votes, and that would then risk crowding out external candidates and more recently promoted core developers that may not have as much personal name recognition.
While the restriction to 5 votes may go some way towards countering that effect, other participants in that thread pointed out that the effect may go in the other direction, with voters choosing to only approve candidates that they already know well, and hence omitting candidates that they would have been OK with, but don’t know as well.