----- Original Nachricht ----
Von: Strainu <strainu10(a)gmail.com>
An: Pywikibot discussion list <pywikibot(a)lists.wikimedia.org>
Datum: 07.08.2016 20:16
Betreff: Re: [pywikibot] Vital sign
016-08-07 19:27 GMT+03:00 Daniel Glus
<danielhglus(a)gmail.com>om>:
On Aug 7, 2016 12:16 PM, "Tobias
Schönberg" <tobias47n9e(a)gmail.com> wrote:
It really seems like WMF should have a full time
employee for Pywikibot
(or if they already do, maybe another one).
Yes, agreed.
>> 1- Pywikibot has the biggest number of open patchsets after
>> mediawiki/core. You might say, it's okay. Pywikibot is completely
>> volunteer-based but ratio of distinct users / open patchsets is
horrifyingly
> high.
As someone who's submitted a few patches, I didn't experience *awful*
delays, but looking at the open patchsets, I have to agree that the
backlog
is disturbingly large.
Thanks for bringing this subject up, Amir! I personally had reviews
taking over a year. Obviously, by that time the change was long
deprecated/useless.
I think a possible solution is empowering more people to review patch
sets.
Making a review guide would help a lot;
publicizing the style guide would
help as well.
I think there were a few steps that hurt PWB in the last few years:
1. Too much branching. For so many years we had both compat and core,
now we went to 2.0/master (if i'm not mistaken). There isn't something
wrong in branching itself, but when you report a bug as a user, you
always need to know on what branch you are. Additionally, there have
been instances where bug reports were... let's say, unwelcomed. For a
(presumably) simple project, a linear development model, with stable
releases and continuous development on top of that should be enough.
Instead of backporting bugfixes, push the users to upgrade.
I agree as I mentioned few months ago. The idea was to publish a stable version. But the
version isn't stable when the environment and dependencies has been changed. And
backporting is a very time consuming process if it is necessary to cherry pick every
single patch from master. I've given up 2.0 and put it out of my scope; it is just to
heavy to synchronize 2.0 with master and keep it up to day or deploy a new release of it.
I feel it is much more difficult as it was between compat and core. We had ~ 250 commits
in master branch but only 18 for core 2.0 in the last 6 months. Enough to discuss whether
this branch is senseless or not.
2. Concentrating on the framework and ignoring the
scripts. The
contributions to the scripts/ folder are few compared to the ones in
pywikibot/. Still, many of the users, especially in smaller wikis,
have little understanding of python beyond very simple changes and
prefer to run already-written scrips.
Main advantage of core branch is to split between the framework library and the scripts
itself. It is normal to have more contributions to the library than for scripts because
scripts use (or should use) standardized and testes bot classes of the library.
Best
xqt