How is it possible that I haven't got any mail from this list since January? Is it dead or have I dropped out?
I've been worried about this project for a very long time. I checked out slowly from pywikibot and I expressed my concerns to the developer relations team privately but after this bug [1], I think it's time to speak out. Disclaimer: I'm not saying pywikibot is dying or will die soon. I'm saying this project is going in unhealthy direction. I'm not de-valuing other people's work and I think they are great but they are missing a few steps that other projects don't.
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. Meaning we have some developers that make a patch and they don't engage in reviewing them even if the patch got -1 or -2 (and funnier sometime they -1 or -2 their own patches) and move on to making other patches. Most of them end up in a obsolete situation needing a rebase or not needed anymore. 2- Developers don't engage in dialogue in proper places so others don't know about issues. No one can subscribe to the phabricator board, it's too big but it would be nice to bring some discussions here. 3- No active developer is connected to other part of wikimedia projects like listening to api announcements. 4- (Sometimes) It's a hostile environment. Behavior of other developers sometimes is demotivating. 5- There's no ArchCom here. I have an approach which might be wrong but another developer comes and disagrees and suggests another approach. I don't like it but there is no place to give the last call so it'll stay at -1 or -2 mode forever. TLDR: Sometimes I feel someone just owns the project and makes patches stuck just by disagreeing on the approach. 6- There is no, absolutely not, a single guide on how to code review. I know code review sucks in Wikimedia technical projects but this one is another level. People send out -2 because "the syntax is ugly" (and the patch is not a fifty nested loops, it's a['foo'] = 1 instead of a['foo'] = True). Mostly they just care about style rather than bugs.
[1]: https://phabricator.wikimedia.org/T142155
I might be wrong and/or out-dated. Correct me please.
Best
On Sun, Aug 7, 2016 at 6:59 PM Bináris wikiposta@gmail.com wrote:
How is it possible that I haven't got any mail from this list since January? Is it dead or have I dropped out?
-- Bináris _______________________________________________ pywikibot mailing list pywikibot@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikibot
@Bináris
I got your message over the mailing list, so that parts seems to work.
@Amir
It really seems like WMF should have a full time employee for Pywikibot (or if they already do, maybe another one). I would often like to fix something, but usually run out of free time before I get something meaningful done. Even writing the Wikidata tutorial is challenging and time consuming.
I think some of your concern could be alleviated if we moved away from gerrit. It is just not as user friendly as other solutions.
-Tobias
2016-08-07 17:01 GMT+02:00 Amir Ladsgroup ladsgroup@gmail.com:
I've been worried about this project for a very long time. I checked out slowly from pywikibot and I expressed my concerns to the developer relations team privately but after this bug [1], I think it's time to speak out. Disclaimer: I'm not saying pywikibot is dying or will die soon. I'm saying this project is going in unhealthy direction. I'm not de-valuing other people's work and I think they are great but they are missing a few steps that other projects don't.
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. Meaning we have some developers that make a patch and they don't engage in reviewing them even if the patch got -1 or -2 (and funnier sometime they -1 or -2 their own patches) and move on to making other patches. Most of them end up in a obsolete situation needing a rebase or not needed anymore. 2- Developers don't engage in dialogue in proper places so others don't know about issues. No one can subscribe to the phabricator board, it's too big but it would be nice to bring some discussions here. 3- No active developer is connected to other part of wikimedia projects like listening to api announcements. 4- (Sometimes) It's a hostile environment. Behavior of other developers sometimes is demotivating. 5- There's no ArchCom here. I have an approach which might be wrong but another developer comes and disagrees and suggests another approach. I don't like it but there is no place to give the last call so it'll stay at -1 or -2 mode forever. TLDR: Sometimes I feel someone just owns the project and makes patches stuck just by disagreeing on the approach. 6- There is no, absolutely not, a single guide on how to code review. I know code review sucks in Wikimedia technical projects but this one is another level. People send out -2 because "the syntax is ugly" (and the patch is not a fifty nested loops, it's a['foo'] = 1 instead of a['foo'] = True). Mostly they just care about style rather than bugs.
I might be wrong and/or out-dated. Correct me please.
Best
On Sun, Aug 7, 2016 at 6:59 PM Bináris wikiposta@gmail.com wrote:
How is it possible that I haven't got any mail from this list since January? Is it dead or have I dropped out?
-- Bináris _______________________________________________ pywikibot mailing list pywikibot@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikibot
pywikibot mailing list pywikibot@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikibot
On Aug 7, 2016 12:16 PM, "Tobias Schönberg" tobias47n9e@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.
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.
What concerns the original issue, I found the error in my filters. Due to interaction of new list name and old filters, all the mails were automatically archived and tagged with Pywikibot-bugs. Did I already told that I hate to spend my time with updating the working environment all the time instead of working? Thanks to Amir, the discussion turned interesting. I just listen, as I was stuck somewhere at Bugzilla and SVN and compat, and couldn't return as developer since that (although I have ideas what to do).
For me, since the move away from SVN I havent contributed due to issues with git
On Sun, Aug 7, 2016 at 1:05 PM, Bináris wikiposta@gmail.com wrote:
What concerns the original issue, I found the error in my filters. Due to interaction of new list name and old filters, all the mails were automatically archived and tagged with Pywikibot-bugs. Did I already told that I hate to spend my time with updating the working environment all the time instead of working? Thanks to Amir, the discussion turned interesting. I just listen, as I was stuck somewhere at Bugzilla and SVN and compat, and couldn't return as developer since that (although I have ideas what to do).
pywikibot mailing list pywikibot@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikibot
Am 07.08.2016 um 19:07 schrieb John phoenixoverride@gmail.com:
For me, since the move away from SVN I havent contributed due to issues with git
I can really understand that. It was a horrible change for me over several weeks or months an I often tended to give up. Anyway I can use it now good enough and due to my experience with that change I published a tutorial [1]. Also a good feature is the gerrit patch uploader [2]; don't care about git/gerrit anymore with it.
Best xqt
[1] https://www.mediawiki.org/wiki/Gerrit/TortoiseGit_tutorial [2] https://www.mediawiki.org/wiki/Gerrit_patch_uploader
@Binaris: Still you can checkout the archive https://lists.wikimedia.org/pipermail/pywikibot/ that it's not active like before. @Tobias: Pywikibot has more developer time than most of projects in WMF thanks to volunteers. What pywikibot is lacking IMO is management time. I would love to see someone from team practices help us or at the very least some people have more authority than just "-2" and "+2"ing and bring discussions and disagreements here, and reach consensus and *enforce* them. @Loic Dachary: I'm super happy that you didn't have the experience I had. That's a good sign.
Best
On Sun, Aug 7, 2016 at 9:35 PM Bináris wikiposta@gmail.com wrote:
What concerns the original issue, I found the error in my filters. Due to interaction of new list name and old filters, all the mails were automatically archived and tagged with Pywikibot-bugs. Did I already told that I hate to spend my time with updating the working environment all the time instead of working? Thanks to Amir, the discussion turned interesting. I just listen, as I was stuck somewhere at Bugzilla and SVN and compat, and couldn't return as developer since that (although I have ideas what to do). _______________________________________________ pywikibot mailing list pywikibot@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikibot
2016-08-07 19:05 GMT+02:00 Bináris wikiposta@gmail.com:
I just listen, as I was stuck somewhere at Bugzilla and SVN and compat, and couldn't return as developer since that (although I have ideas what to do).
That's not correct, I wanted to say Sourceforge and SVN. :-)
016-08-07 19:27 GMT+03:00 Daniel Glus danielhglus@gmail.com:
On Aug 7, 2016 12:16 PM, "Tobias Schönberg" tobias47n9e@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. 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.
I also have some other issues with certain strategic decisions, but I have no proof those were bad by themselves.
Regarding the proposed solutions, I am wary of the WMF "taking over" the development of pwb (call me old fashion if you like, but I'm still not over 2014). Also, more reviewers without a clear direction do not help. I used to have +2 a while ago, but I dropped out anyway because I couldn't understand where the main developers were taking pwb.
I'd much rather feel like contributing to a roadmap for development (so users can have a clear picture of were pwb is heading) doubled by some kind of commitee deciding on the debatable commits - all of those community driven, possibly with someone from WMF as facilitator if you think that would help.
Best, Strainu
pywikibot mailing list pywikibot@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikibot
Strainu strainu10@gmail.com writes:
Regarding the proposed solutions, I am wary of the WMF "taking over" the development of pwb (call me old fashion if you like, but I'm still not over 2014). Also, more reviewers without a clear direction do not help. I used to have +2 a while ago, but I dropped out anyway because I couldn't understand where the main developers were taking pwb.
I completely agree with you in the case of larger changes (e.g. architecture changes or feature requests), but I think there could be more reviewers to help with smaller patches, such as trivial or minor bug fixes. Surely one doesn't need a vision or direction to recognize that we should be keeping up with breaking API changes, or to help with the backlog of obsolete patches? (I'd help, but, again, a good patch reviewing guide would be immensely helpful.)
Am 08.08.2016 um 04:03 schrieb Daniel Glus danielhglus@gmail.com:
Strainu strainu10@gmail.com writes:
Regarding the proposed solutions, I am wary of the WMF "taking over" the development of pwb (call me old fashion if you like, but I'm still not over 2014). Also, more reviewers without a clear direction do not help. I used to have +2 a while ago, but I dropped out anyway because I couldn't understand where the main developers were taking pwb.
I completely agree with you in the case of larger changes (e.g. architecture changes or feature requests), but I think there could be more reviewers to help with smaller patches, such as trivial or minor bug fixes. Surely one doesn't need a vision or direction to recognize that we should be keeping up with breaking API changes, or to help with the backlog of obsolete patches? (I'd help, but, again, a good patch reviewing guide would be immensely helpful.)
As I mentioned 6 mentioned 6 months ago there are a lot of trivial patches and improvements for the framework as well as for scripts to be reviewed. I am unhappy of this delay an ask me to fork and create my own branch because in my production copy most files are changed and it is hard to keep an overview.
Anyway we have a lot of +2 coder but only a few who reviews the patches. We could give some guys +2 rights. There are some trivial patches to get experience in reviewing.
I know reviewing treaters sets is more difficult and time consuming. It is easier to write the code than reviewing it when trying to understand the proposed improvement and its code. Any test suite helps.
I would invite you to participate.
Best Xqt
Am 08.08.2016 um 07:40 schrieb Bináris wikiposta@gmail.com:
Call me dumb, but what do +2 and -2 exactly mean? _______________________________________________
I don't call you but I am sorry for missing explanation. +2 is the revie right to merge a patch whereas -2 blocks a patch. -1 means there is a problem to be solved and +1 means the patch looks good but another must review.
Best Xqt
I am only user, not developer. And it seems to me there is many changes around some pyflakes, travis, test and some other weird stuff, but there are many "minor bugs" (probably easy to solve) in end-user scripts, but nobody is solving them for many months.
I reported many bugs on interwiki.py (which is still used in wiktionary), some of them are about two years old and without solution [1] There are also old bugs preventing intewiki.py from autonomous run from toolserver [2]
There are also bugs in solve:disambiguation (which is still better in compat), there are enhancement requests for commons.py...
Whot abouy some debug-a-thlon for these script?
[1 ]https://phabricator.wikimedia.org/T74943 [2] https://phabricator.wikimedia.org/T74674
JAnD
--- Ing. Jan Dudík projekce dopravních staveb tel. 777082195
2016-08-08 7:58 GMT+02:00 info info@gno.de:
Am 08.08.2016 um 07:40 schrieb Bináris wikiposta@gmail.com:
Call me dumb, but what do +2 and -2 exactly mean? _______________________________________________
I don't call you but I am sorry for missing explanation. +2 is the revie right to merge a patch whereas -2 blocks a patch. -1 means there is a problem to be solved and +1 means the patch looks good but another must review.
Best Xqt _______________________________________________ pywikibot mailing list pywikibot@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikibot
2016-08-08 7:58 GMT+02:00 info info@gno.de:
I don't call you but I am sorry for missing explanation. +2 is the revie right to merge a patch whereas -2 blocks a patch. -1 means there is a problem to be solved and +1 means the patch looks good but another must review.
Here: https://gerrit.wikimedia.org/r/#/c/306409/ I see that jenkins-bot gave a +2. So the bot has the right to do it? In which cases?
2016-08-08 7:58 GMT+02:00 info info@gno.de:
I don't call you but I am sorry for missing explanation. +2 is the review right to merge a patch whereas -2 blocks a patch. -1 means there is a problem to be solved and +1 means the patch looks good but another must review.
Here: https://gerrit.wikimedia.org/r/#/c/306409/ I see that jenkins-bot gave a +2. So the bot has the right to do it? In which cases?
There is a difference between code review and code verify flag. The verify flag is set by the autoreviewer jenkins-bot after some automatic tests are done. There are some syntactical and style checks but also some code checks which are automatically done after a new patch is uploaded and also when a patch ready to merged into the branch by a code reviewer flag CR+2.
see: https://www.mediawiki.org/wiki/Gerrit/Tutorial#How_code_is_reviewed_in_Gerri...
-- Bináris
Best
Xqt
----- Original Nachricht ---- Von: Strainu strainu10@gmail.com An: Pywikibot discussion list pywikibot@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@gmail.com:
On Aug 7, 2016 12:16 PM, "Tobias Schönberg" tobias47n9e@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:
- 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.
- 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
I think some of your concern could be alleviated if we moved away from gerrit. It is just not as user friendly as other solutions.
-Tobias
Please don't. I remember the last change from svn to git/gerrit and I am not interested on another time consuming change. I fear I'll give up then.
Best Xqt
FYI you can now edit patches directly at gerrit and even create them directly there too. One has to be careful with TABs but other than that I've found that useful, specially for small fixes or patch fixes.
I'm not a developer so I can't really have an opinion here. Maybe gerrit would have its flaws, but IMHO is not that bad.
Regards, M.
El jueves, 11 de agosto de 2016, info info@gno.de escribió:
I think some of your concern could be alleviated if we moved away from
gerrit. It is just not as user friendly as other solutions.
-Tobias
Please don't. I remember the last change from svn to git/gerrit and I am not interested on another time consuming change. I fear I'll give up then.
Best Xqt _______________________________________________ pywikibot mailing list pywikibot@lists.wikimedia.org javascript:; https://lists.wikimedia.org/mailman/listinfo/pywikibot
On Thu, 2016-08-11 at 02:47 +0200, info wrote:
I think some of your concern could be alleviated if we moved away from gerrit.
Just for the records, Wikimedia's Gerrit instance will get replaced at some point by Phabricator Differential... See https://www.mediawiki.org/wiki/Phabricator/Differential
andre
2016-08-24 20:20 GMT+02:00 Andre Klapper aklapper@wikimedia.org:
Just for the records, Wikimedia's Gerrit instance will get replaced at some point by Phabricator Differential... See https://www.mediawiki.org/wiki/Phabricator/Differential
When?
I just made an effort to familiarie myself with gerrit, so this was not worth again? It would be so nice to deal with effective working instead of changing work environments just as underpants all the time. The best choice would STILL be to take Pywikibot back to SourceForge and SVN...
There is an RFC about project hosting. All options are git, and SourceForge does support git.
https://www.mediawiki.org/wiki/Requests_for_comment/pywikibot_git_hosting
In my opinion, going back to SVN will seriously hurt the project, and I think Github is a better choice than SourceForge but I dont mind either option.
On Wed, 31 Aug 2016 21:46 Bináris, wikiposta@gmail.com wrote:
2016-08-24 20:20 GMT+02:00 Andre Klapper aklapper@wikimedia.org:
Just for the records, Wikimedia's Gerrit instance will get replaced at some point by Phabricator Differential... See https://www.mediawiki.org/wiki/Phabricator/Differential
When?
I just made an effort to familiarie myself with gerrit, so this was not worth again? It would be so nice to deal with effective working instead of changing work environments just as underpants all the time. The best choice would STILL be to take Pywikibot back to SourceForge and SVN...
-- Bináris _______________________________________________ pywikibot mailing list pywikibot@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikibot
On Wed, 2016-08-31 at 16:46 +0200, Bináris wrote:
2016-08-24 20:20 GMT+02:00 Andre Klapper aklapper@wikimedia.org:
Just for the records, Wikimedia's Gerrit instance will get replaced at some point by Phabricator Differential... See https://www.mediawiki.org/wiki/Phabricator/Differential
When?
We don't know yet. If we knew, it would be written on the wiki page. As you know how to use Git (and Gerrit), the difference should not be as huge as it was when moving from archaic SVN to Git.
andre
Hi,
I recently took an interest in pywikibot and was warmly welcomed on the IRC channel, including a guided tour to be oriented. After creating a simple minded bot using pywikibot/wikidata, I browsed the pending project issues[1] with a focus on those related to wikidata, to give back with a few bug fixes. Some were marked as "easy" so I tried and a few were merged after a few days. Much to my surprise, I got quick and useful feedback on gerrit, which is a sign of vitality, IMHO. That kept me going and I even tried to help with reviews as well. Only two/three of the pending reviews had no comments: I did not get lucky, almost all proposed patches caught the attention of at least one reviewer. Today I addressed comments on my latest bug fix and discovered aspects of the Wikibase API which I did not know[2].
I realize this is a subjective view from a newcomer but here it is ;-)
Cheers
[1] https://phabricator.wikimedia.org/project/view/87/ [2] https://phabricator.wikimedia.org/T138287
On 07/08/2016 16:29, Bináris wrote:
How is it possible that I haven't got any mail from this list since January? Is it dead or have I dropped out?
-- Bináris
pywikibot mailing list pywikibot@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/pywikibot