I'm finishing up the evaluation portion of my API client library
internship project. As a part of that, I'm making sure that
feedback/bug reports/feature requests end up where they should be. I
made several suggestions at the end of the pywikibot-core
evaluation, and have been linking bugzilla issues to some of the
criteria. I also left comments on the documentation RFC  with the
This leaves a handful of larger-scale/general/structural suggestions for change:
* As of 25 July 2014, there are 105 open patches in gerrit. The patch
review process should be streamlined and/or prioritized to reduce the
backlog of unreviewed patches.
* Iterating over a list and calling the API for each item is an
inefficient use of API calls. Pywikibot could be made more efficient
by combining API calls as much as possible (e.g. using generators and
combining resultstitle=title1|title2|...). One option may be a
constructor method that collects Page requests and enables larger,
less frequent API calls.
* The initial installation process features a series of obscure
options and confusing installation documentation. Redesign the initial
installation/configuration process to be lighter-weight, soliciting
and valuing feedback from new or one-time users in the redesign
process. Is it necessary to be logged in before `import pywikibot`
will not cause an error?
* Foster a hospitable attitude on pywikipedia-l, especially to new
and/or inexperienced users. Consider agreeing on community standards
for interaction; the Hacker School social rules may be a useful
Is Bugzilla the best place for these? Would these be useful to discuss
at the pywikibot hackathon at Wikimania? Is there somewhere else these
suggestions ought to go?
from pywikibot gold-standard evaluation