On Thu, May 13, 2021 at 10:03 PM Stephen J. Turnbull < turnbull.stephen...@u.tsukuba.ac.jp> wrote:
> *Creating* plausible issues is hard work, I assure you as a university > professor. Coming up with "exercises" that are not makework requires > expertise in both the domain and in educational psychology. (Some > people are "just good at it", of course, but it's quite clear from > popular textbooks that most are not.) I think that would be a very > unproductive use of developer time, especially since "git clone; git > checkout some-tag-in-2017" is pretty much what you're asking for > otherwise. Maybe selecting already solved issues which theoretically takes away the pain of mimicking real-world scenarios. Great to have the insights from someone behind the scenes of exercises The problem is not a lack of issues to practice on. It's that (1) the > PR process itself is a barrier, or at least an annoyance, and (2) many > new contributors need mentoring. (Or think they do. Some just need > encouragment, others need help on technique, but both groups are more > or less blocked without the mentoring.) > I think setting up is not that hard. VStinner contributed a great piece in the sense of https://cpython-core-tutorial.readthedocs.io/en/latest/ if someone gets stuck, he can ping the list or something like that . Like once you set the project running i guess what you need is contribute or explore and understand, both theoretically solved using the educational repo. Like you need to find something to do before the interest wanes away. As Terry Reedy encourages, getting more and more people to contribute ensures that at least a couple of people passes through the vital processes need to get people going/becoming a regular contributor. This idea aims to make this process easier. And, of course, real contribution involves a lot of unfun work. > Writing tests, writing documentation, explaining to other developers > who start out -1 because they don't get it, overcoming your own mental > blocks to changing your submission because *you* don't get it, and on > and on. A lot of newcomers think "I'm not good at that, if I have to > do it I can't contribute" (and a few selfishly think they can just do > the fun parts and achieve fame and fortune), but you know, "if not > you, then who? If you don't do it for Python, where are you going to > be able to contribute?" > Having past solved issues picked out and documented some more in increasing level of difficulty seems to iron out the issues. > To be honest, although I'm not a specialist in organizational behavior > and am operating with a small sample, I can say that from the point of > view of identifying tasks, finding solutions, and implementing them, > Python is the most effective non-hierarchical organization I've ever > seen. I can't say I've seen more than one or two hierarchical > organizations that are significantly better at implementing solutions > and don't burn up their workers in the process -- and the ones I'm > thinking of are way smaller than Python. (Yes, I know that there are > people who have gotten burned up in Python, too. We can do better on > that, but Python does not deliberately sacrifice people to the > organization.) > I agree that the Python community is awesome, the different WGs act like great departments, people do give a lot of time but being subscribed in here for some years made me see some recurring patterns. Also, while organising FlaskCon, we got some really great insights into the community. The usergroup page where usergroups are listed is a big lie in the sense that though is lists all usergroups once initiated, the real picture is way different. We contacted a great deal of them. Here and there there is room for improvement in the machinery. > I have to point out that there's a whole crew over on corementorship > doing this work, and at least one Very Senior Developer with their own > private mentoring program.[1] IMO, that is a big part of why Python > is as successful as it is. If more senior developers would take on > these tasks it would have a big effect downstream. But emotional work > is hard, and it comes in big chunks. In many situations you have to > follow through, on the mentee's schedule, or the mentee will "slip the > hook and swim away." So it's a big ask. I'm willing to make that ask > in the abstract, but there's not even one senior developer I'm able to > point to and say "definitely that person would do more for Python by > mentoring than by hacking". It's a very hard problem. > That's why i guess what i am proposing might seem simple but it's fundamentally putting CPython contribution mentoring in auto-pilot mode. I've seen as i said VStinner's initiative and initiatives like these pay off far more than just the docs though it can be included in the docs, but having some tidbit liberty addresses some on the fly issues. But not all people have time for that as juggling work, life and OpenSource is a great problem to solve. Personally i intend to help setting up the basics of it but it requires me to become a regular contributor, in the meanwhile, sharing some obeservations, ticking off some todos until i resume interest in tackling issues. Kind Regards, Abdur-Rahmaan Janhangeer about <https://compileralchemy.github.io/> | blog <https://www.pythonkitchen.com> github <https://github.com/Abdur-RahmaanJ> Mauritius
_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-le...@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IDUW2KSZASTR64EX7E6ZK6ITQBXJZ6L3/ Code of Conduct: http://python.org/psf/codeofconduct/
