I asked Stefan some questions and here is he answer.
27.03.19 10:25, Stefan Behnel пише:
Hi Serhiy!
It's actually good that you asked. Please forward this to the committers
list for me.
Serhiy Storchaka schrieb am 27.03.19 um 07:40:
Maybe it's my fault that I did not introduce you well enough, but there
were some questions.
No problem. They are good questions, and the discussion around them was
probably also necessary at some point.
Why do you want to be the core developer? Why do you
need these rights? Do you fully understand that this is not just rights,
but above all certain responsibilities.
Do you want to be a maintainer of the xml.etree package (and maybe other
XML modules)?
I understand that it's a responsibility. I accept that responsibility, and
yes, I think the XML packages would benefit from a couple more hands and
heads, as would other parts of CPython. I also understand the difference
between writing a PR and being able to merge it. :)
Besides that, I think the position also gives a different standing, both in
the circle of core devs and in the community, even though some core-devs
are arguing against codifying that. I find it perfectly ok to strive for
recognition in an unpaid job. The PSF is one way of giving out recognition,
but it's not the only way. Being equal can sometimes be more valuable than
being special.
Regarding the process, I think it's good to have a grey zone in the ways
how to become a core developer. It should be easy enough to not scare away
candidates (because we need them!), but still have a bar that keeps people
out who just want a nice title for their resume and then drop away after a
couple of months.
Why is that? Because there are costs associated with new core devs:
1) They need initial support and training, thus eating up the contributed
time of other core developers. Adding new core devs should have the
ultimate goal of *reducing* the time that others need to put into the
project to get work done, not increase it.
2) Adding a new core dev increases the chance of dissent between people who
can click merge buttons and revert commits. Managing groups of people is
difficult, at least if there is more than one person involved.
3) Revoking the rights of a former contributor is a major social problem,
thus leading to stale entries in the list of core-devs. (*)
Thus, IMHO, the main questions to answer when deciding whether to add a new
core dev are: 1) Is that person knowledgeable enough for the job and
capable/expected to take over tasks from others? 2) Can that person be
expected to participate in decision processes in a constructive way, and
without starting merge wars? 3) Has that person been around for long enough
to safely assume that it's not just a flash in the pan?
Apart from that, given the social bar that someone has to promote a person
(and probably wouldn't do that if that person is unlikely to pass the
acceptance test), I think it's an acceptable process.
It's a bet on the future, after all. Life and conditions change, and you
can never be sure how a person will behave in a year's time, if that person
will still be willing and capable of contributing then, or if that person
will even be alive at all. Predictions are hard, especially about the
future. We have to live with that, and adjust the tradeoffs accordingly.
Stefan
(*) The German language has the beautiful word "Karteileiche" for this,
literally a dead body in a register.
_______________________________________________
python-committers mailing list
python-committers@python.org
https://mail.python.org/mailman/listinfo/python-committers
Code of Conduct: https://www.python.org/psf/codeofconduct/
