[Mailman-Developers] Getting mentor attention [was: Mailman SNMP support]

[Stephen J. Turnbull]

Nitin Agarwal writes:

 > Here its Nitin Agarwal, an open source Software developer and
 > enthusiast.

Hi, pleased to meet you.  I'm belatedly replying to the list, and at
length, as there are other students in your situation.  I hope it
helps.

First off, I saw you talked to Terri on IRC.  Much as I hate to burden
Terri, that is the right thing to do if you're not getting attention
to your proposal, especially from persons who proposed or volunteered
to mentor it.  If at all possible, try to grab GSoC people on IRC (or
by email) in the following order:

1.  Any other mentor or active developer, to get comments first.
2.  Barry.
3.  Terri or Florian.
4.  Jessica (real last resort).

Contact info for the above is on the "Ideas" page.

Barry isn't official in GSoC, but he's head of the Mailman project and
a ranking demi-god in the Pytheon.  Also crazy busy, so you may get a
polite brushoff.  OTOH, he can probably solve Mailman problems in half
the time of anybody else.  And if Barry asks for help, someone will
respond.

Terri and Florian are PSF org admins, not just Mailman IIUC.  Crazy
busy, too, but dealing with problems is their job as org admin.  As
org admins, to some extent they can knock heads.  You don't really
want that, except as a last resort.

Jessica is PSF org admin, with no specific interest in Mailman.  A
really last resort, because it implies Terri and Florian are asleep at
the wheel.

N.B. They all *like* talking to people when they've got time.  Don't
be *afraid* to talk to them.  But it's better to spread yourself
around (or as the Japanese say, develop a wide face) and get to know
more people in the project, especially at the start.

 > I am looking forward to contribute to Mailman in the upcoming
 > Google Summer of Code 2014 through the Mailman SNMP Support Project
 > idea. I have an experience with the open source software
 > development and tools used.

This is a "good enough" short self-introduction.  However, it doesn't
shine.  It's like providing a numerical answer on a math test, without
showing your work.  (Boy do I hate it when students do that....)

Specifying languages (and implementations), maybe applications and
libraries, related to the project that you have worked with, or
especially "on", polishes the image.  Mention projects (an URL to your
github page is just another numerical answer -- tell us about your
work!)  But keep it short (yes, I know it's difficult to do both).

Image is important -- we mentors are all human, bright shiny things
attract our attention.  That's part of why we need org admins -- not
everybody has image skills[1], so somebody has to go looking for and
polishing up those diamonds in the the rough.  But you can better your
chances by not depending on the org admins to get attention for your
proposal -- do it yourself.

 > I have an indepth knowledge of SNMP protocol and an understanding
 > of the concepts specified in the SNMP RFC 1157.

Although I'm willing to co-mentor this project, when you first posted
I was able to expand "SNMP" but that was the extent of my knowledge.
(Standards geeking is one of the things I'm good at, I'm pretty sure I
can catch up. :-)  I had no clue about why Mailman would want it or
who requested it or who would mentor it.  So I didn't respond.  The
two "whos" are our bad (they should be on the "Ideas" page, partly
remedied now).

But it's important that *you* explain *why* you chose that feature.
It's OK to just say "it's in my toolkit" (and do be honest about your
motivations -- mentoring is a "trust" relationship).  But, again, your
proposal shines when you tell us why *we* (or our users) want it.

So you (or any student) can greatly improve your chances of getting
someone to engage by telling us "why" we want it.  You do that by
focusing on the *user requirements* rather than on the *design and
implementation* ("use this protocol" is design; "use this library" is
low-level design, aka a plan for implementation).  Everybody on this
list is a Mailman *user* (broadly defined as list members, list admins
of several flavors, and site admins), but not all are *developers*.
If you can get some users saying "hey, *I* could *really* use that
feature," it's more attractive to the developers and mentors (and we
always have more desirable features than slots).  But remember, users
often don't know the buzzwords like SNMP (or even SMTP, and RFC
numbers are quite arbitrary).  Concretely, what are the benefits to
subscribers and/or admins?  Tell stories about situations where this
feature would help.  Describe how it would operate (from the user's
viewpoint, not the protocol itself).

N.B.  This advice isn't universal.  In some projects, mentors are core
developers who are looking for someone "just like them", who knows the
protocol and just wants to dive in and implement a pre-specified
feature.  (That's typical for compiler optimizations, for example.)
But I think it's pretty good advice for Mailman at the present time.

                                *****

About this specific project, my initial reaction was "we *have* an
NMP" (usually called "the REST interface").  Why do we need another
network management protocol, even if it's "simple"?  Remember, "there
should be one-- and preferably only one --obvious way to do it" is a
fundamental principle of design for Python developers.[2]  What does
SNMP do for us that the REST interface doesn't?

Pop quiz (relevant to that last question): What statement in Sec. 1.3
of RFC 3411 immediately caught my eye?  Hint: which letter in "FCAPS"
caught my eye?  (To readers not interested in implementing SNMP in
Mailman as a GSoC intern: *don't* answer on-list!!  This quiz is for
prospective interns on the SNMP project!)  Why are they interesting?

Do you propose to replace the RESTful interface, or to have two
interfaces?  (This question is not a quiz, it's a research question --
quite possibly you may finish your project and still not have a fully
satisfactory answer to that.)

Another question: RFC 1157 is labelled "historic".  It's been
obsoleted several times.  I realize that the current set of related
RFCs counts at least 5 (what's "simple" about that?!), but ISTM there
are important reasons why we really want the modern versions.  Are you
familiar with the important changes in goals for the newer RFCs?

Footnotes: 
[1]  Note that "English is my second language" is not an excuse.
Every post I've seen so far is perfectly understandable, and nobody
needs to be ashamed of their English.  The issue is that working on
Mailman at the present time requires understanding user requirements,
so do the best you can to tell stories about your project that end
with users living happily ever after!

Yes, I know, second languages cost.  I work in a second language that
is easily the most difficult ever invented -- Japanese.  But (unless
you're very fortunate in finding a mentor who speaks your language),
you will have to get over that, so I discount the cost -- you've
already decided to pay it.

[2]  If you're not familiar with these programming proverbs, type
"python -m this".