Results of the "mentoring" experiment Re: Metaproblem, part 3

[João Távora]

Eli Zaretskii <address@hidden> writes:

>> From: address@hidden (João Távora)
>> Cc: Eli Zaretskii <address@hidden>,  address@hidden,  address@hidden,  
>> address@hidden
>> Date: Sat, 06 Dec 2014 07:07:21 +0000
>> 
>> To test the process, I can volunteer to submit a couple of reasonably
>> small ideas, between 100 and 300 LOC, that need a mentor (*).
>
> Please go ahead, and thanks.
>
> Of course, to be practical, there's a need for a mentoree for each
> such idea, but if that's you, then that issue is solved.

Hi,

On Friday, I pushed darkroom.el to ELPA.git, as one of my "reasonably
small ideas" that I setup for the "mentoring experiment" to ELPA.git. I
consider the experiment finished:

Here are some notes:

* I posted two emails with two "mentor requests". One had a couple of
  replies the other had none.

* From one of the replies (this thread or
  https://lists.gnu.org/archive/html/emacs-devel/2014-12/msg00808.html),
  three or four iterations with Rasmus ensued until the code was mostly
  clean of obvious mistakes, according to Emacs coding-style rules and
  so on. Rasmus also helped clarify much of the functionality and
  insisted on good docstrings for example.

* Doing this on-list went OK, with not too much noise. Stefan
  contributed some very small, but useful comments. After Rasmus gave
  the go-ahead more or less informally, Dmitry Gutov and Martin Rudalics
  each gave some final advice and resolved the final blockers. I get the
  feeling there were some followers of the thread, because visits spiked
  at my github upstream. Richard Stallman also expressed curiosity about
  what the "darkroom hack" was. Stephen Turnbull complained about being
  in Cc. Sorry, for some reason I only say that mail today. You're in Cc
  now because you predicted "an early demise of this experiment."  and
  I'm interested in knowing your thoughts now that it's over.

  Anyway, after some silence, I pushed to git.

* According to Rasmus, the mentoree must do some effort in this phase to
  convincingly present the utility of his extension, and how it
  differentiates from the rest.

* According to Rasmus, and I agree, availability and commitment of
  mentors depends on the personal interest they have in the
  code. Apparently Rasmus had used something similar to darkroom.el

* Rasmus' interest motivated me to actually do the work and really clean
  it up.

* Changing subject line prefixes to express the state of the process
  didn't please Rasmus much. I guess it's a stupid way to emulate a bug
  tracker.

* It's really very easy to distract oneself into the implementation
  details (for example "loop" vs "reduce") during what I idealized that
  the mentoring phase should be. There has to be some force to focus on
  the procedure-based blockers (copyright assignment, git workflow, big
  flaws in code) and separate them from the rest of the analysis etc.

* My opinion is that this can work, but there have to be some guidelines
  in place (like manual, CONTRIBUTE or README) so that mentors and
  mentorees are aware of some minimal formality in their roles. It went
  OK without it, but could go better. Also Rasmus prefers it to be
  called "peer-review".

* I found that the information that is sought after in this phase is
  practically all written down and available already, but spread across
  the Elisp manual, wikipedia, the ELPA.git README, git tutorials,
  etc. A nice aggregation of this information would be useful, but this
  was in the original discussion I believe.

I guess the whole idea of mentoring is that a person with some
experience is the best aggregator and additionally provides (a lot of)
motivation to clean your stuff up and contribute.

Thanks everybody and bye!
João