
On Fri, Jul 31, 2015 at 9:37 AM, Carl Meyer <carl@oddbird.net> wrote:
I'm a Django core developer. For the last half-year or so, the Django Software Foundation has (for the first time) paid a "Django Fellow" or two (currently Tim Graham) to work on core Django. For me the experience has been excellent.
So based on my experience with the transition to having a DSF-paid Fellow on the Django core team, and having watched important python-dev work (e.g. the core workflow stuff) linger due to lack of available volunteer time, I'd recommend that python-dev run, not walk, to ask the PSF board to fund a similar position for Python core.
Of course there may be differences between the culture of python-dev and Django core
A view from the other side. Yeah I guess its a good idea for PSF to spend some money to clear 'ugly' bugs. Dunno about the proc-n-cons of this so wont get into it. Instead I'd like to draw attention to the free side of the equation -- What would it take to have more hands with sleeves rolled up and doing the housecleaning? Context: We had a bunch of college students (2nd year Engineering) doing some projects with us. One was inside the CPython sources: https://github.com/rusimody/l10Python Their final presentation was last Thursday. Q: Is there anything in there that can reasonably be a patch for python? A: Please dont be embarrassing! However as a student project it was enough for us to say: "Good work!" Here's an REPL-session to demo: [Note १२३४५६७८९० is devanagari equivalent of 1234567890] -------------------------------------------------- Python 3.5.0b2 (default, Jul 30 2015, 19:32:42) [GCC 4.9.2] on linux Type "help", "copyright", "credits" or "license" for more information.
१२ 12 23 == २३ True १२ + ३४ 46 १२ + 34 46 "12" == "१२" False 2 ≤ 3 True 2 ≠ 3 True (λ x: x+3)(4) 7 # as a result of which this doesn't work... I did say they are kids! ... δ = 3 File "<stdin>", line 1 δ = 3 ^ SyntaxError: invalid syntax {1,2,3} ∩ {2,3,4} {2, 3} {1,2,3} ∪ {2,3,4} {1, 2, 3, 4} ¬ True False Σ([1,2,3,4]) 10
The last is actually more an embarrassment than the δ breaking since they’ve *changed the lexer* to read the Σ when all that was required was Σ = sum !! In short... Kids! However as kids we could say they are farther to being programmers than they were before this -- opening something of the scale of CPython, finding one's way around and adding/modifying even the tiniest bit of functionality is a big growing-up step. Brings me to the point of this mail: Surely me+my students is not unique configuration -- there must be zillions of such across the world. And if inexperienced/kids like us had more help from people like the members of this list we would get farther and at least some subset of these may go on to become actual devs/contributors. So the request is that some of you give a tiny fraction of your time to teams just mucking around in the CPython codebase as a long term investment to producing more devs even when it is not directly connected to a possible contribution/patch. [Yeah I am a lurker on the mentors list but I dont see much *technical* discussion happening there] We could actually submit patches. Just that the priorities of the 3 parties -- teachers, students, devs -- is clearly different: - Teachers need to give/create a good learning experience - Students need to shine, do well, excel...("show off" is not an inaccurate description) - Devs need the language to progress and bugs to be fixed Though these priorities are different I believe a symbiosis is possible. In particular, at least some of the -- for a dev -- 'ugly-bugs' could be a challenge in an academic context. I will be teaching again to more advanced students this time If I could find a path through bugs of different challenge-levels we may get some bugs fixed... Thanks Rusi -- http://blog.languager.org

On Sun, 02 Aug 2015 21:47:23 +0530, Rustom Mody <rustompmody@gmail.com> wrote:
[Yeah I am a lurker on the mentors list but I dont see much *technical* discussion happening there]
Yes, it's a mentoring list for how to contribute, not for technical issues, though we happily get in to technical issues when they arise.
We could actually submit patches. Just that the priorities of the 3 parties -- teachers, students, devs -- is clearly different: - Teachers need to give/create a good learning experience - Students need to shine, do well, excel...("show off" is not an inaccurate description) - Devs need the language to progress and bugs to be fixed
Though these priorities are different I believe a symbiosis is possible. In particular, at least some of the -- for a dev -- 'ugly-bugs' could be a challenge in an academic context.
The issues that haven't been responded to are *an* issue, but not in fact our most pressing one. The bigger problem, that a Fellow would solve, is not fixing bugs at all (although in Django's case apparently the Fellow does handle security issues...we have an active group of committers who address those, so I don't think a Python Fellow would need to write patches for those, just possibly shepherd them through). The need is to do the "ugly" *job* of making sure that issues that have patches get reviewed, the patches improved, and *get applied*, and, yes, that all issues get a reply. (This is actually a job I enjoy doing, but all I've been managing in my unpaid time lately is trying to keep up with tracker triage and making technical/procedural comments on some issues.) If we had the kind of support a Fellow would provide then your students could actually get valuable feedback by submitting patches (as long as they were willing to take patch criticism!). I'm not *sure* that would be a good thing, as it would increase the review load of patches from less experienced developers, but personally I'd encourage it anyway to help kids (and other less experienced developers) *become* good developers. Python has always had an educational mission, after all :) Rob's suggestion of core devs trying to review one 'commit review' patch a day (or whatever rhythm works for them) could move us toward this goal without a Fellow. I'm going to try to get back to doing that. But realistically, we can't count on busy people being able to make that kind of time consistently available for free, or being interested on working on parts of Python that, well, they aren't interested in.
I will be teaching again to more advanced students this time If I could find a path through bugs of different challenge-levels we may get some bugs fixed...
Like I said, our problem isn't getting the bugs fixed, it is getting the fixes *reviewed* and *applied*. (Yes, there are some bugs that languish because no one is interested in doing the grunt work to fix them, but I bet that problem would take care of itself if people were more confident that patches would actually get applied when completed.) Having your students *review* and improve existing patches that haven't been moved to 'commit review' and aren't being actively worked on would be just as useful as finding bugs without patches to work on (and easier to do). I think it would just as valuable educationally, or perhaps more so, because they have a starting point, learn about code quality, and figure out how *improve* code (thus learning about better coding practices). Unfortunately there is no good path to finding "appropriate" bugs. My own technique, used for the pycon sprints, is just to hit 'random issue' and evaluate the doability (ie: it's not hung up waiting for a decision from core) and difficulty level and putting it on a list accordingly. That does in some cases require enough experience with the codebase to make those judgements, but there are a lot of issues that are fairly obvious on their face as to how difficult they are. --David
participants (2)
-
R. David Murray
-
Rustom Mody