jessenoller.com

So, after my ini­tial pro­posal to Python-Dev about the core men­tor­ship pro­gram I received a pretty impres­sive out­pour­ing of sup­port and inquiries from peo­ple — both men­tors and “stu­dents” look­ing to join into the pro­gram. Frankly, I’m floored at how pos­i­tive the response has been.

I got the mail­ing list up in short order (go here), and any­one who expressed inter­est to me, or on the python-dev list was directed to it — we have a total of 57 mem­bers right now, and many of the men­tors have sent intro­duc­tions to the list. We’ve also to hashed out the ini­tial code of con­duct, as well as pro­duc­tively answered questions.

Things seem on track — mod­ulo my inabil­ity to carve off time to deploy the small sta­tic about site to pythonmentors.com — on my task list for today. Just to share for your own edi­fi­ca­tion, below is our python-inspired (mean­ing: sim­ple, suc­cinct) code of con­duct for the mail­ing list:

The fol­low­ing code of con­duct is not meant as a means for pun­ish­ment, action or cen­sor­ship for the mail­ing list or project. Instead, it is meant to set the tone and expec­ta­tions and com­fort level for men­tors and those wish­ing to be men­tored on the list.

• We ask every­one to be wel­com­ing, friendly, and patient.
• Flame wars and insults are unac­cept­able in any fash­ion, by any party.
• Any­thing can be asked, and “RTFM” is not an accept­able answer.
• Nei­ther is “it’s in the archives, go read them”.
• List archives are avail­able only to sub­scribers, but sub­scrip­tion is open to everyone.
• Since the archives are “closed” — cross post­ing to pub­lic mail­ing lists is discouraged.
• State­ments made by core devel­op­ers can be quoted out­side of the list.
• State­ments made by oth­ers can not be quoted out­side the list with­out explicit per­mis­sion. [1]
• We endorse the PSF’s Diver­sity state­ment.
• The list admin­is­tra­tors reserve the right to revoke the sub­scrip­tion of mem­bers (includ­ing men­tors) that per­sis­tently fail to abide by this Code of Con­duct. [2]

[1] Anonymised para­phrased state­ments “some­one asked about…” are ok — direct quotes with or with­out names are not appro­pri­ate.
[2] All men­tors are signed up as administrators.

The next steps are to get the basic site up (noth­ing fancy) and to get a blog post up on the newly minted python insider blog. Oth­er­wise: I encour­age those look­ing to learn and con­tribute to join in, the water is fine.

So, after my ini­tial pro­posal to Python-Dev about the core men­tor­ship pro­gram I received a pretty impres­sive out­pour­ing of sup­port and inquiries from peo­ple — both men­tors and “stu­dents” look­ing...

*wipes the dust off the blog*

*cough* Now that PyCon 2011 is slightly behind us/me — I’ve man­aged to eke out time to draft and pro­pose some­thing that’s been gnaw­ing at me for some time — propos­ing a Python-Core men­tor­ship pro­gram. You can see the python-dev thread here, but I have also reposted the email below. I’m inter­ested in thoughts/feelings/feedback about the idea.

Hello every­one:

I wanted to take a moment to out­line another idea which came out of PyCon 2011 this year from numer­ous sources — a Python Core Men­tor­ship Pro­gram pred­i­cated on the idea that Python-Core, and Python as a whole would be served by fur­ther low­er­ing the bar­rier to entry of con­tri­bu­tion, and to pro­vide a pro­gram to con­nect new pro­gram­mers, stu­dents, women, and oth­ers to expe­ri­enced Python-Core devel­op­ers (Mentors).

Brett’s revamp of the Dev guide was part one of “secret plan to get more peo­ple involved in python-core” — this is another part, but I’m not sure of the num­ber­ing scheme.

The mis­sion of the Python Core Men­tor Pro­gram is to pro­vide an open and wel­com­ing place to con­nect stu­dents, pro­gram­mers — and any­one inter­ested in con­tribut­ing to the Python-Core devel­op­ment. This project is based on the idea that the best way to wel­come new peo­ple into any project is a venue which con­nects them to men­tors who can assist in guid­ing them through the con­tri­bu­tion process, includ­ing dis­cus­sions on lists such as python-dev, and python-ideas, the bug tracker, mer­cu­r­ial, code reviews, etc.

Addi­tion­ally, men­tors will assist in some­thing incred­i­bly crit­i­cal to main­tain con­trib­u­tor inter­est: get­ting patches through the process and actu­ally *com­mit­ted*. We all know — not every­one who is men­tor will have all the answers, so men­tors also act as con­duits to oth­ers who will have the answer.

The project itself will (hope­fully) be low in time-spent, and largely self-managing. We will start sim­ple with a mail­ing list (core-mentorship at python.org) where men­tors, and those who wish to be men­tored or ask ques­tions may do so. This mail­ing list will have a code of con­duct which will help pre­vent flame wars, or other coun­ter­pro­duc­tive dis­cus­sions — a code of con­duct also makes it clear to men­tors what they’re agree­ing to when they decide to participate.

The new list will also have a closed, members-only archive. After con­sult­ing with other core devel­op­ers, we believe it’s eas­ier to ask ques­tions when you don’t have to worry about Google pick­ing up your words from a pub­lic archive. We want to make this list a resource for peo­ple to be able to get started, ask “silly” ques­tions, and so on — our goal is to turn any­one who wishes to be into an active, sus­tain­able com­mit­ter to Python.

Men­tors will be asked to answer ques­tions — but also assist peo­ple in need of help with dis­cus­sions on the mail­ing lists and bug tracker (con­ver­sa­tions on which could have become con­tentious or stress­ful) and gen­er­ally to be advo­cates for the peo­ple being men­tored. For exam­ple — if a per­son sub­mits a patch to the tracker, the men­tor list may help them through ini­tial code reviews, or dis­cus­sions with other core devel­op­ers. The job is to act as an expe­ri­enced proxy for them.

The first step to this project is to ask for vol­un­teer men­tors — peo­ple who are will­ing to help answer ques­tions on the list, and gen­er­ally guide peo­ple as needed being as friendly and cour­te­ous and wel­com­ing as possible.

If you are inter­ested in being a men­tor — or have feed­back about this plan in gen­eral, please feel free to reach out to me (jnoller at gmail.com) directly. My goal, once this is setup, is to have the project largely self-managing, with the PSF help­ing to mar­ket it to the com­mu­nity as a whole.

Jesse

Update: We’ve launched, and we’re doing well — check out this post right here for more infor­ma­tion and the code of conduct.

*wipes the dust off the blog* *cough* Now that PyCon 2011 is slightly behind us/me — I’ve man­aged to eke out time to draft and pro­pose some­thing that’s been gnaw­ing at...

Whew. Where did the time go. I swear, it was only a few weeks ago when we were stand­ing in Atlanta together at PyCon 2010 laugh­ing it up and hav­ing a blast (albeit me with a busted ankle). Time flies. It really, really flies.

That said — as I stated on the PyCon 2011 blog, we’ve offi­cially announced all the talks and tuto­ri­als for the con­fer­ence this year:

• List of accepted tutorials
• List of accepted talks and panels

This year was par­tic­u­larly dif­fi­cult for the pro­gram com­mit­tee (the group in “charge” of select­ing talks) — some of which I go into in the announce­ment. We had so many awe­some talks, and an abbre­vi­ated time­line, a new site, the hol­i­days and a lot more to con­tend with. Look­ing at the pro­gram though, things look amaz­ing. Addi­tion­ally, we’ve already lined up one amaz­ing keynote speaker, and are work­ing on at least one other.

Not to men­tion — we’re lin­ing up an impres­sive array of spon­sors (yes, Nasuni is one as well) — if you know of a com­pany using python who might be inter­ested in being a PyCon spon­sor (yes, it’s totally worth it) — send them our way. If you have ques­tions — please reach out to us at pycon-sponsors@python.org — spon­sors get a lot of ben­e­fits, and they help out the con­fer­ence and com­mu­nity immensely. Remem­ber, any funds which count as “profit” for the con­fer­ence go straight to the Python Soft­ware Foun­da­tion.

PyCon 2011 looks like it’s shap­ing up incred­i­bly well — but it’s not going to be much of any­thing with­out you. Yes, you. PyCon isn’t PyCon with­out all of you in the com­mu­nity show­ing up and mak­ing it sim­ply the best pro­gram­ming con­fer­ence out there in terms of wel­come­ness, intel­li­gence and fun. But not only have we had to cap total reg­is­tra­tion to 1500 peo­ple — the early bird dead­line for reg­is­tra­tion is approach­ing a lot more quickly then you’d think! (Jan­u­ary 17th) — so you’ve got to get reg­is­tered!

Finally — get the word out, and vol­un­teer! We always need help spread­ing word about PyCon, and this year is no dif­fer­ent. We are also always look­ing for on-the ground staff and other vol­un­teers to help us when the con­fer­ence rolls around! Check out:

• The Pub­lic­ity page
• The Vol­un­teer page

Whew. Where did the time go. I swear, it was only a few weeks ago when we were stand­ing in Atlanta together at PyCon 2010 laugh­ing it up and hav­ing...

Van says it all here — but I’ll quote it nonetheless:

While the pro­gram com­mit­tee toils away over the record num­ber of talk and tuto­r­ial sub­mis­sions, we are pleased to announce that reg­is­tra­tion is now open for PyCon 2011. Get your tick­ets early, because for the first time, we will have to cap this year’s reg­is­tra­tion at just 1500 spots.

Some­thing most peo­ple don’t know about me is that I am a data geek. So, being who I am, I have gone back through the sta­tis­tics for the past four years of PyCon to see if I could find any way of gaug­ing the health of the con­fer­ence from early in the cycle. I found that there was an almost per­fect cor­re­la­tion between the num­ber and tim­ing of the talk sub­mis­sions for PyCon and the final attendance.

This year, we got more talk and tuto­r­ial sub­mis­sions than ever before in the his­tory of PyCon. We broke the pre­vi­ous records by double-digit per­cent­ages in every category.

I shouldn’t have been too sur­prised. We started hear­ing peo­ple get excited about this upcom­ing PyCon eight months ago. To keep from over­whelm­ing our venue, we have decided that we need to cap atten­dance at 1500 peo­ple. We also promised that those who sub­mit­ted a talk or tuto­r­ial pro­posal would be guar­an­teed a slot, mean­ing that of those 1500 tick­ets, approx­i­mately 250 are already spo­ken for.

Early bird reg­is­tra­tion rates are effec­tive until Jan­u­ary 17. Reg­u­lar reg­is­tra­tion rates will run from Jan­u­ary 18th until March 1 — if there are any spots left. More infor­ma­tion is avail­able on the reg­is­tra­tion page as well as a direct link to our reg­is­tra­tion site.

Go here to register.

  Van says it all here — but I’ll quote it nonetheless: While the pro­gram com­mit­tee toils away over the record num­ber of talk and tuto­r­ial sub­mis­sions, we are pleased...

Check out the post I just threw up on the PyCon 2011 blog over here — the short ver­sion is that we got over 200 talk pro­pos­als! This is awe­some, and makes the pro­gram committee’s job that much harder. If you want to help out, ping me at jnoller at python dot org.

Check out the post I just threw up on the PyCon 2011 blog over here — the short ver­sion is that we got over 200 talk pro­pos­als! This is awe­some,...

Why is it, that when­ever I think things will calm down, they do the exact opposite?

Well — you should know by now that the PyCon 2011 Call for Pro­pos­als is up — we’re accept­ing main con­fer­ence talks, poster ses­sions and tuto­ri­als, all at once. The main con­fer­ence pro­pos­als are due by Novem­ber 1st — so I’d rec­om­mend get­ting those talks in! Also, you should know that we’ve announced our first keynote speaker — Hilary Mason! Really, really look­ing for­ward to that.

Over on the sprints side — Brian Curtin has done sev­eral blog posts — the first details the “get­ting started with Python-Dev” guide he’s been shep­herd­ing for the project. I’d rec­om­mend tak­ing a look — you can send feed­back to sprints@python.org. The sec­ond is a note on the fact we have our first com­pany donat­ing actual funds to the project (via the PSF) — Trad­ing Tech­nolo­gies. This is awe­some news.

If you want to do a sprint — and you want some money to help out, please, please, please send an appli­ca­tion to sprints@python.org — we cur­rently do not have any sprints lined up in the near future (We are spon­sor­ing the ?http://www.pymntos.com/ sprint occur­ring tonight — they’re port­ing Mute­gen to python 3). If you need help, or want help send­ing out a call for a sprint, con­tact us too. Our goal is to help every­one get sprints up and off the ground.

Also, if you want to help out with the sprints project — please let me know. We need blog­gers, writ­ers and other peo­ple to help fur­ther “the cause”.

Finally, I’ve been spend­ing the major­ity of my time once again blog­ging for my employer (Nasuni) — if you’re inter­ested, I recently did a series on “The Cloud” (focus­ing on Pri­vate vs. Pub­lic clouds), while Rob (my boss) did a fan­tas­tic post on the real cost of a giga­byte in the cloud:

• Pri­vate vs. Pub­lic Cloud 1: The five key attrib­utes of the Cloud.
• ?Pri­vate vs. Pub­lic Cloud 2: Defin­ing Pub­lic ver­sus Pri­vate Clouds.
• ?Pri­vate vs. Pub­lic Cloud 3: Which option is best for you?
• What is the (real) cost of a giga­byte in the cloud?

Why is it, that when­ever I think things will calm down, they do the exact opposite? Well — you should know by now that the PyCon 2011 Call for Pro­pos­als...

I’ve just started send­ing out notices to all the mail­ing lists and sites — the Pycon 2011 Call for Pro­pos­als is now open. You can check it out here — we’ve got a brand new web­site, and a rock­ing group of vol­un­teers. I encour­age any­one who thinks they might be inter­ested in sub­mit­ting a talk pro­posal and volunteering!

I’ve just started send­ing out notices to all the mail­ing lists and sites — the Pycon 2011 Call for Pro­pos­als is now open. You can check it out here —...

I’ve obvi­ously been quiet here on my per­sonal blog — as every­one who reads reg­u­larly knows I’m neck-deep in a pretty excit­ing startup call Nasuni as well as doing other projects, like the PSF Spon­sored sprints thing. That com­bined with twit­ter means my time for other addi­tional long-form con­tent is min­i­mal. So here’s a small roundup of inter­est­ing things:

Nasuni

Yup, still run­ning Python and Django! We’re actu­ally pretty proud to be a spon­sor for Djan­go­Con 2010 com­ing up in Sep­tem­ber — I’ll be attend­ing, so I hope to see all the famil­iar Django faces I know, and meet some new ones.

I’ve been blog­ging semi-regularly for the Nasuni blog itself — my posts are focused on product-things more than any­thing else. Here’s a small list of posts which I’ve done:

• The Road to Release — Fea­ture Pre­views — this is actu­ally my lat­est one, and the first in a series where I’ll be show­ing off some of the new fea­tures we’re adding in the lat­est release.
• Look­ing at Open­Stack, a Rack­space and NASA ini­tia­tive — For those of you who don’t know, Rack­space and NASA announced Open­Stack — the awe­some part? It’s all python — I had the swift com­po­nent (which pow­ers Rackspace’s cloud­files sys­tem) of Open­Stack run­ning pretty quickly. I’d rec­om­mend snag­ging the code from launch­pad and tak­ing a look. Swift (the stor­age com­po­nent) uses event­let — and Nova (the com­pute part) uses Tor­nado and Twisted.
• Stor­age Switzer­land Test Dri­ves the Filer — This is a response to an arti­cle writ­ten about the prod­uct — I actu­ally used it to pre­view some of the work going into the next release of the Filer.
• Thanks to Django — This piece goes into some detail about our use of Django, it’s one of our ways of say­ing thanks. I still need to rework it so we can send it over for the Django Suc­cess Sto­ries page.
• Thanks to the Sup­port­ing Cast — This is an ear­lier thank you post — but to the other peo­ple who have helped out a ton, includ­ing Greg New­man, Lin­coln Loop, and Revsys.
• The Donut Solu­tion — This was a fun one, mainly to show that yes — we’re lis­ten­ing hard to cus­tomer feed­back, and we’re improving/iterating quickly. Also, I get to show off UI improvements.
• Finally — The Nasuni Blog team — this is the rosetta stone for the authors of the blog, describ­ing who we are. I didn’t write this piece, but it’s good read­ing to fig­ure out who is who.

If you’re inter­ested in Nasuni — or cloud stor­age in gen­eral — I’d encour­age you to sign up for the RSS feed. We’re try­ing to keep the infor­ma­tion use­ful out­side of “just us” (despite my urge and predilec­tion to churn­ing out com­pletely product-related posts) — and if you ever have feed­back, drop us a line.

PSF Spon­sored Sprints

The project con­tin­ues on — we’ve funded two sprints so far, and have sev­eral more com­ing down the pike. We’re always in need of vol­un­teers to help us do things like the man­u­als and site maintenance/content author­ing. Here’s some highlights:

• The call for appli­ca­tions is open — The call for appli­ca­tions is open — and now I sus­pect we won’t be clos­ing it. Orig­i­nally, I thought we’d have to do things in waves of apply-approve. As time has pro­gressed, I no longer think this is the case.
• Mon­treal Python Pack­ag­ing sprint wrap up — the wrap up report for our first sprint!
• Europy­thon core sprint report - another wrap up report for the core sprint we pro­vided funds to.
• Just added the loca­tions page — we now have people/companies offer­ing up space for sprint­ers! Check it out!
• Finally - Sprints at PyOhio — PyOhio is going on this week­end, if you’re in the area you should really go check it out! Cather­ine has gone above and beyond with the entire “become a con­trib­u­tor” effort going on.

Please! If you’re think­ing about hold­ing a sprint - send us an appli­ca­tion! Heck, even if we’re not spon­sor­ing it, we’ll help pro­mote you via the blog, and the sprint cal­en­dar we have up. A lit­tle fact? The sprints we’ve funded so far, and that are on deck for fund­ing are all out­side of the US, which is both awe­some, and surprising!

PSF Board

Some of you prob­a­bly know that I’m cur­rently on the board of direc­tors for the PSF — things progress well here, but I mainly wanted to call out the excel­lent blog Doug Hell­mann has been author­ing for PSF news. You should really be watch­ing that because yes — we do do things, and hope­fully over the next year, we’ll be doing more awe­some things.

I’ve actu­ally got a big­ger post in the works for what I think the ulti­mate mis­sion of the PSF is/should be as well as “how do you get money from us” as well. Must find the time!

I’ve obvi­ously been quiet here on my per­sonal blog — as every­one who reads reg­u­larly knows I’m neck-deep in a pretty excit­ing startup call Nasuni as well as doing other...

The Google Test­ing Blog has a good post up right now by James Whit­taker called “There, but for the grace of test­ing, go I” — it’s a good read, and a per­ti­nent one for any of you/us who feel strongly about quality.

Even though I’ve spent more time then not on “the other side” of the table (Devel­oper, noun — “focus on mak­ing soft­ware (ergo, bugs)”) I find that James’ words ring pretty loudly for me still, espe­cially his part on risk analysis:

I am thank­ful that the vast major­ity of bugs that affect entire user pop­u­la­tions are gen­er­ally nuisance-class issues. These are typ­i­cally bugs con­cern­ing awk­ward UI ele­ments or the occa­sional mis­fir­ing of some fea­ture or another where workarounds and alter­na­tives will suf­fice until a minor update can be made. Seri­ous bugs tend to have a more local­ized effect. True recall class bugs, seri­ous fail­ures that affect large pop­u­la­tions of users, are far less com­mon. Testers can take advan­tage of the fact that not all bugs are equally dam­ag­ing and pri­or­i­tize their effort to find bugs in the order of their seri­ous­ness. The futil­ity of find­ing every bug can be replaced by an inves­ti­ga­tion based on risk.

I’d rec­om­mend James’ post amongst the oth­ers there on that blog — it reminded me of an old rant of mine “The cost of (not) test­ing soft­ware”. Any­one in the busi­ness of mak­ing some­thing is also in the busi­ness of mak­ing bugs. It’s impor­tant for us to keep that in mind when we deal with our day to day job — and when we think about our cus­tomers. It’s also impor­tant for us to keep that in mind when crit­i­ciz­ing or drag­ging any per­son or com­pany or code through the muck.

The Google Test­ing Blog has a good post up right now by James Whit­taker called “There, but for the grace of test­ing, go I” — it’s a good read, and...

Back in May, Guido assigned me “single-use” BDFL pow­ers when decid­ing on the state of PEP 3148. I had been work­ing on and off with Brian since his orig­i­nal pro­posal to the stdlib-sig mail­ing list.

Tonight, I “offi­cially accepted” the PEP Brian’s put a lot of work into. You can check out the PEP itself, or play with the code over here. The credit goes to Brian, and the small army of peo­ple who gave him feed­back includ­ing Jef­fery Yasskin who spent a fair amount of time iter­at­ing and expound­ing on things.

Below, is a snip­pet from one of my orig­i­nal emails to python-dev on my rea­son­ing for sup­port­ing the library, and also adding in the “con­cur­rent” namespace.

Baloney. A young library pro­vid­ing some syn­tac­tic sugar which uses
prim­i­tives in the stan­dard library to imple­ment a com­mon pat­tern is
fine for a PEP. We’ve hashed this out pretty heav­ily on the stdlib-sig
list prior to bring­ing it here. By the same argu­ment, we should shunt
all of the recent unittest changes and improve­ments into space, since
golly, other peo­ple did it, why should we.

This is some­thing rel­a­tively sim­ple, which I would gladly add in an
instant to the mul­ti­pro­cess­ing pack­age — but Brian’s one-upped me in
that regard and is pro­vid­ing some­thing which works with both threads
and processes hand­ily. Take a look at multiprocessing.Pool for exam­ple
- all that is some sugar on top of the prim­i­tives, but it’s good
sugar, and is used by a fair num­ber of people.

Let me also state — “my” vision of where futures would live would be
in a con­cur­rent pack­age — for example:

from con­cur­rent import futures

The rea­son *why* is that I would like to also move the abstrac­tions I
have in mul­ti­pro­cess­ing *out* of that mod­ule, make them work with both
threads and processes (if it makes sense) and reduce the
mul­ti­pro­cess­ing mod­ule to the base prim­i­tive Process object. A
con­cur­rent pack­age which imple­ments com­mon pat­terns built on top of
the prim­i­tives we sup­port is an objec­tively Good Thing.

For exam­ple, how many of us have sat down and imple­mented a thread
pool on top of thread­ing, I would haz­ard to say that most of us who
use thread­ing have done this, and prob­a­bly more than once. It stands
to rea­son that this is a com­mon enough pat­tern to include in the
stan­dard library.

In any case; con­sider me a strong +1 to adding it.

With that done, I am back to being only the benev­o­lent dic­ta­tor of my lawn, which is mostly dead.

Also, for added fun — check out the PyCon AU talk Brian did!

Back in May, Guido assigned me “single-use” BDFL pow­ers when decid­ing on the state of PEP 3148. I had been work­ing on and off with Brian since his orig­i­nal pro­posal...