State of Pidgin: Attracting and Maintaining New Contributors

[Gary Kramlich]

Greetings Programs!

If you have not yet seen the introduction email with a subject of "State of
Pidgin: Introduction", please go read it first.

As anyone who's followed the project knows, we've been suffering from a
lack of contributors for quite some time now.

I believe there are many reasons to this.  Many of which I'm trying to
address in these emails.  I've already taken steps for a few of the other
ones.

One of the biggest issues I hear when people are deciding to contributor to
an open source project is how active that project is.  Up until recently,
it was very hard to gauge how active we were, and that was because we
weren't very active.  To combat this, as many of you know, I started live
streaming my contributions to all things Pidgin related on
https://twitch.tv/rw_grim.  These streams are intended to work on project
and it's surrounding infrastructure only and are not meant for user
support.  The stream has brought in quite a few new contributors and
hopefully more in the future.

Next up is our code is freaking intimidating.  That is one of the principal
reasons that I want to split the repository.  It's very hard to find code
in our code base, even for me, who has been working in it (on and off
again) for the past 14 years.  That's not okay.  A lot of this confusion
can be fixed by renamespacing stuff and splitting files up.  We have
multiple files that are more than 10,000 lines long, that's crazy.  It
makes navigating those files way harder than it should be when you have to
jump 3000 lines between the blocks that you're working on.

While our API reference documentation is pretty decent, we have next to
nothing when it comes to getting started documentation.  Ethan put together
a high level, this is how pidgin is structured document long ago that's in
one of his blogs and John put together a ton of stuff for plugin
development, but most of it is outdated now.  I started combating this with
the first "skeleton" repository https://bitbucket.org/pidgin/s
keleton-libpurple.  This repository is meant to be forked by new plugin
authors and serve as a skeleton which includes an example plugin, a build
system, and documentation for how it all comes together.  I haven't really
announced it yet, because I need to get a few people to try it out and
provide some feedback and I haven't had an opportunity to present it yet.

I have also started translating a bunch of our wiki pages into markdown and
have them in https://bitbucket.org/pidgin/nest.  The idea here is to
provide a more stream lined approach to general documentation by using pull
requests in a markup that people are more familiar with than genshi
templates (what trac uses).  This also gives us the ability to review
everything, and since it's in markdown, we can eventually host it on
https://readthedocs.org.

I have a few more ideas too, but this has already gotten very winded and
would like to hear what everyone else has to say.

Please discuss.

Thanks,

--
Gary Kramlich <grim at reaperworld.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://pidgin.im/pipermail/devel/attachments/20171003/aeb01408/attachment.html>