http://toolserver.org/~phe/statistics.php now says "403: User account expired"
This madness has to stop. Wikisource depends on this service. I understand the German toolserver is beyond repair, but phe's statistics scripts should be moved to proper WMF servers.
Back in April, I copied one set of phe's graphs to Commons, where we can go for a nostalgic look at the once existing statistics graph system that phe built, and that worked fine until the German toolserver gang decided to ruin it, http://commons.wikimedia.org/wiki/Category:ProofreadPage_Statistics
Toolserver users need to renew their accounts every so often[1] (Three monthly is combing to mind, but someone else would need to confirm (and they are given warnings I believe)), and if a user fails to do that it is automatically locked, It's unfair to all TS users if user accounts are allowed to exist forever using the shared resources of a free service.
I think you should reconsider the tone you used in this email as it came over as being extremely harsh and consider apologising.
Perhaps you could try to contact Phe and ask that they login to their account and run the renewal process?
On Mon, 21 May 2012 at 23:52 +0000, Lars Aronsson wrote:
http://toolserver.org/~phe/statistics.php now says "403: User account expired"
This madness has to stop. Wikisource depends on this service. I understand the German toolserver is beyond repair, but phe's statistics scripts should be moved to proper WMF servers.
My bad, I forget to renew my account, trouble should be solved within a few days.
Hello, At Tuesday 22 May 2012 00:11:49 DaB. wrote:
My bad, I forget to renew my account, trouble should be solved within a few days.
I extended the account until July, please extend it further yourself.
Sincerely, DaB.
Hello, At Tuesday 22 May 2012 00:03:06 DaB. wrote:
http://toolserver.org/~phe/statistics.php now says "403: User account expired"
This madness has to stop. Wikisource depends on this service. I understand the German toolserver is beyond repair, but phe's statistics scripts should be moved to proper WMF servers.
the user phe has not specified a default-license and the code of the URL you posted has no license-notice too, so the code and the script will go to nowhere. The only possibility to get the tool back is that phe returns. (I doubt BTW that the WMF would host a unsupported tool).
Sincerely, DaB.
On 21 May 2012 23:52, Lars Aronsson lars@aronsson.se wrote:
This madness has to stop. Wikisource depends on this service. I understand the German toolserver is beyond repair, but phe's statistics scripts should be moved to proper WMF servers.
This madness has to stop. Wikis should stop depending on services that are not hosted in multi-maintainer projects!
Okay, I can understand that wikis do not care about Toolserver internal procedures. I think there are several improvements we can make - I've listed my thoughts below.
The main problem: tools are disappearing and users of the tools get annoyed by that. There are two directions of improvement on that: a) make sure the tools do not disappear b) make sure users know tools can disappear suddenly
How do we make sure tools do not disappear? By making multi-maintainer projects for them. However, we see that this doesn't happen enough - see also the thread about the expiration of soxred93's account.
Options for improvement: - better communication with wikis - which tools are used a lot and *thus* should be moved to mmp's? - easier creation of mmp's? I can imaging people don't move their tools because it takes time to organise everything. - 'barnstars' - mmp's are awesome, because you're improving the TS and improving the user experience by moving your tools to an mmp. People should be praised for moving their tools! - Actively checking for links to the toolserver from wiki's (we have the DB - it's a trivial query!) to non-mmp-tools, and actively communicating that non-mmp-tools that are linked to a lot should move. - ...
How can we make sure users know tools can disappear suddenly? Effectively, all tools /not/ in mmp's are in continuous alpha stage: they can disappear at /any/ stage. However, we are not communicating this to users.
Options for improvement: - More explicit communication that all tools can disappear suddenly /unless/ noted otherwise - combined with having a 'stable project' note on all mmp's - Re-introduction of the stable.toolserver.org domain - or possibly changing the naming scheme to 'unstable.toolserver.org' for all general tools and 'mmp-name.toolserver.org' for mmp tools. + bonus: a more awesome domain name might persuade more people to move their tools - A big fat banner "THIS TOOL IS UNSTABLE AND CAN DISAPPEAR AT ANY TIME" above every non-mmp-tool. - ...
In general, let's see how we can improve this situation. I think it's certainly not 'beyond repair' or 'unproper', but I do think there is room for improvement.
Best, Merlijn
On Tue, May 22, 2012 at 10:22 AM, Merlijn van Deen valhallasw@arctus.nl wrote:
On 21 May 2012 23:52, Lars Aronsson lars@aronsson.se wrote:
This madness has to stop. Wikisource depends on this service. I understand the German toolserver is beyond repair, but phe's statistics scripts should be moved to proper WMF servers.
This madness has to stop. Wikis should stop depending on services that are not hosted in multi-maintainer projects!
I don't think that's realistic. There is barely enough of us (volunteer programmers) as it is; co-maintaining someone else's code would add a significant workload.
I have repeatedly offered all my tools for MMPs - so far, only CommonsHelper2 and geohack are MMPs.
Magnus
Magnus Manske magnusmanske@googlemail.com wrote:
On Tue, May 22, 2012 at 10:22 AM, Merlijn van Deen valhallasw@arctus.nl wrote:
On 21 May 2012 23:52, Lars Aronsson lars@aronsson.se wrote:
This madness has to stop. Wikisource depends on this service. I understand the German toolserver is beyond repair, but phe's statistics scripts should be moved to proper WMF servers.
This madness has to stop. Wikis should stop depending on services that are not hosted in multi-maintainer projects!
I don't think that's realistic. There is barely enough of us (volunteer programmers) as it is; co-maintaining someone else's code would add a significant workload.
I recently switched to an MMP for some project we depend on heavily (http://toolserver.org/~citegen/ - citation template generator) and I found out not everything works like on a normal account.
For example, our webserver interface does not set $HOME in the environment, so for each project I might need to hardcode its base directory:
https://jira.toolserver.org/browse/TS-1341 Webserver FastCGI interface does not set $HOME
Probably something like __FILE__ from PHP should be used but the point was to migrate a working tool and work on refactoring together later.
//Saper
On 22/05/12 21:54, Marcin Cieslak wrote:
I recently switched to an MMP for some project we depend on heavily (http://toolserver.org/~citegen/ - citation template generator) and I found out not everything works like on a normal account.
For example, our webserver interface does not set $HOME in the environment, so for each project I might need to hardcode its base directory:
https://jira.toolserver.org/browse/TS-1341 Webserver FastCGI interface does not set $HOME
Probably something like __FILE__ from PHP should be used but the point was to migrate a working tool and work on refactoring together later.
//Saper
Note you can use __DIR__ in the php version installed in the toolserver.
On 22/05/12 11:22, Merlijn van Deen wrote:
How do we make sure tools do not disappear? By making multi-maintainer projects for them. However, we see that this doesn't happen enough - see also the thread about the expiration of soxred93's account.
Options for improvement:
- better communication with wikis - which tools are used a lot and
*thus* should be moved to mmp's?
- easier creation of mmp's? I can imaging people don't move their
tools because it takes time to organise everything.
It's relatively hard to create a MMP. Compare that with the complexity of doing a mkdir for creating a project in your account. Add to that the relatively low interest of other people for maintaining external projects (as shown by Magnus mail). There's little reason to create a MMP in advance. Plus, each of is coding using different languages, conventions and "frameworks" (helper functions).
Maybe we should use a model where stable tools are available in a repository where all users can commit. The code can only be updated through that. As an alternative, each project could be in either open-gate or closed-gate model. In the first one, anyone can commit there. In the second one, there's just a subset of users which can directly commit (commits by others must be approved by a project member). If the accounts for all the project members expire (it gets orphan), the tool automatically changes to open-gate mode.
On Tue, May 22, 2012 at 1:30 PM, Platonides platonides@gmail.com wrote:
On 22/05/12 11:22, Merlijn van Deen wrote:
How do we make sure tools do not disappear? By making multi-maintainer projects for them. However, we see that this doesn't happen enough - see also the thread about the expiration of soxred93's account.
Options for improvement: - better communication with wikis - which tools are used a lot and *thus* should be moved to mmp's? - easier creation of mmp's? I can imaging people don't move their tools because it takes time to organise everything.
It's relatively hard to create a MMP. Compare that with the complexity of doing a mkdir for creating a project in your account. Add to that the relatively low interest of other people for maintaining external projects (as shown by Magnus mail). There's little reason to create a MMP in advance. Plus, each of is coding using different languages, conventions and "frameworks" (helper functions).
Maybe we should use a model where stable tools are available in a repository where all users can commit. The code can only be updated through that. As an alternative, each project could be in either open-gate or closed-gate model. In the first one, anyone can commit there. In the second one, there's just a subset of users which can directly commit (commits by others must be approved by a project member). If the accounts for all the project members expire (it gets orphan), the tool automatically changes to open-gate mode.
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
An other idea, albeit one requiring more planning, coding, and cooperation (and we are notoriously bad at two of these) would be to separate front-end and back-end. If we could set up a MMP that presents an API for the queries and data storage of several tools, anyone (at the very least, anyone on the toolserver) could write a front-end; also, taking over a front-end from someone else might be more maintenance-friendly.
We could even offer consistent stylesheets for toolserver tools (hey, one can dream?)
Cheers, Magnus
On 2012-05-22 11:22, Merlijn van Deen wrote:
This madness has to stop. Wikis should stop depending on services that are not hosted in multi-maintainer projects!
This would be an improvement over the current status, but it is not sufficient. It's terrible that we depend on a single user, but not much better if we depend on a small group of them. We have got the WMF and its staff to keep things running, and that's where this kind of statistics belongs. The WMF are carefully considering whether new projects should be started, they have agreed that Wikisource should be started (in 2003) and as a consequence, vital statistics and support should be funded and operated by them.
b) make sure users know tools can disappear suddenly
But you have no way to communicate this message. It's an impossible task.
Hello, At Tuesday 22 May 2012 19:00:14 DaB. wrote:
We have got the WMF and its staff to keep things running, and that's where this kind of statistics belongs. The WMF are carefully considering whether new projects should be started, they have agreed that Wikisource should be started (in 2003) and as a consequence, vital statistics and support should be funded and operated by them.
that's the reason why there is a toolserver: Because the WMF (and the mediawiki-develeopers/techs) can not do everything themself and there are several people with good ideas outside the WMF. So the idea was "we give them a (yes 1 ;-)) server and they can hosts their stuff there (in opposite to host it somewhere external)" – that part worked quite well; there was also a second part "and than their stuff can move into mediawiki when it is done and the code is good enough (and it has to be php…)." – that part never worked (at least I do not know an example). In my eyes the toolserver developed behind this original idea and is now a good place to host stuff even when it is done, because the toolserver-cluster is now way more stable and complete than a single server could be (yes, there IS much more to improve, I know). If you (the ts-users) would start to move more stuff into MMPs it would be even more stable – BTW: You do not have to find a co-maintainer to start a MMP, you can run it all alone. The advantage of a MMP (besides that it does not expire at the moment) is that someone can continue to run the tools even if the original maintainer left the TS.
Sincerely, DaB.
On Tue, May 22, 2012 at 6:16 PM, DaB. WP@daniel.baur4.info wrote:
In my eyes the toolserver developed behind this original idea and is now a good place to host stuff even when it is done
Just like Wikipedia was to Nupedia. Symmetry! :-)
On 22/05/12 19:16, DaB. wrote:
that's the reason why there is a toolserver: Because the WMF (and the mediawiki-develeopers/techs) can not do everything themself and there are several people with good ideas outside the WMF. So the idea was "we give them a (yes 1 ;-)) server and they can hosts their stuff there (in opposite to host it somewhere external)" – that part worked quite well; there was also a second part "and than their stuff can move into mediawiki when it is done and the code is good enough (and it has to be php…)." – that part never worked (at least I do not know an example).
If some of you needs help moving a php tool into a MediaWiki extension, drop me a line. :)
Platonides platonides@gmail.com wrote:
On 22/05/12 19:16, DaB. wrote:
that's the reason why there is a toolserver: Because the WMF (and the mediawiki-develeopers/techs) can not do everything themself and there are several people with good ideas outside the WMF. So the idea was "we give them a (yes 1 ;-)) server and they can hosts their stuff there (in opposite to host it somewhere external)" – that part worked quite well; there was also a second part "and than their stuff can move into mediawiki when it is done and the code is good enough (and it has to be php…)." – that part never worked (at least I do not know an example).
If some of you needs help moving a php tool into a MediaWiki extension, drop me a line. :)
. o O (only not to be allowed to run it on toolserver later?:)
On 25/05/12 23:12, Marcin Cieslak wrote:
If some of you needs help moving a php tool into a MediaWiki extension, drop me a line. :)
. o O (only not to be allowed to run it on toolserver later?:)
Perhaps we may be able to make it a cross-tool, which can either be embedded in MediaWiki or standalone (I'm not aware of any extension doing that, but it's something I have considered several times myself).
On Sat, May 26, 2012 at 8:47 AM, Danny B. Wikipedia.Danny.B@email.cz wrote:
Perhaps we may be able to make it a cross-tool, which can either be embedded in MediaWiki or standalone (I'm not aware of any extension doing that, but it's something I have considered several times myself).
CategoryTree was/is sort of that...
So was GeoHack.
On Tue, 2012-05-22 at 11:22 +0200, Merlijn van Deen wrote:
- easier creation of mmp's? I can imaging people don't move their
tools because it takes time to organise everything.
This. IMO, ideally it _should_ be as easy as running a script to create the project (the admins can always close disused or mistakenly created projects later) and copying the code (and any associated databases, cron jobs, etc.) over. No bureaucratic pre-approval, no code changes, no fuss.
As Marcin Cieslak notes, it doesn't work quite that smoothly yet. If nothing else, I think it really would help if we could at least make the execution environment as identical as possible for both MMPs and private tools.
Also, I think the name "multi-maintainer project" is discouraging on two counts: the "multi-maintainer" part makes it sound like you need to find a second maintainer to create one (which, as DaB notes, is not true), and the "project" part makes them sound like some complicated thing that's overkill for just one simple script (which is what most tools are).
Also, the whole practice of using such a complicated-sounding term (or, worse yet, an acronym) for MMPs makes them seem like a special case, as opposed to the default case of private tools (which we just call plain old tools). Of course, historically that _has_ been the case, but if we want to change that, we might as well start with the names.
I hereby propose that we retire the term "multi-maintainer project" or "MMP", and just start calling them "public tools" (with an appropriate qualifier where necessary, as in "public tool account"), as opposed to "private tools" that run on users' personal accounts. I do realize that these names are not perfectly descriptive, but IMO they're at least better than what we have right now.
(I did consider "stable" instead of "public", but I feel that that still presents a needless psychological barrier; it takes a lot of time and testing to be sure that a new tool really is stable, and we don't really want people to wait that long before making their tools public. In fact, it's precisely the unstable-but-useful tools that most benefit from the possibility of having multiple maintainers.)
Ps. I'm sort of talking from experience here: I have a bot running on my account that's been performing a useful service for Commons for a few years now, and whose continued operation in the future really should not depend on whether I remember to renew my account or not. I've just never got around to applying for an MMP for it, pretty much for the reasons that I've tried to analyze above.
On Wed, May 23, 2012 at 6:09 PM, Ilmari Karonen nospam@vyznev.net wrote:
On Tue, 2012-05-22 at 11:22 +0200, Merlijn van Deen wrote:
- easier creation of mmp's? I can imaging people don't move their
tools because it takes time to organise everything.
I hereby propose that we retire the term "multi-maintainer project" or "MMP", and just start calling them "public tools" (with an appropriate qualifier where necessary, as in "public tool account"), as opposed to "private tools" that run on users' personal accounts. I do realize that these names are not perfectly descriptive, but IMO they're at least better than what we have right now.
I agree with Ilmari.
Except I don't see the problem with the word "project" and "Public Tool Account" is asking for more scary abbreviations.
I'd recommend the name "Public projects" or "Shared projects" (instead of "Public tools"). Most accounts contain multiple tools. Since an MMP is just a shared account, it can perfectly contain multiple (related) scripts, or a framework, or collection of interconnected tools.
"Creating a public tool" (where one would previously say "Creating a MMP") sounds a bit off to me. "Creating a public project" or "Creating a shared project" sounds more natural to me.
Anyway, that's just terminology. I agree with Ilmari's reasoning.
-- Krinkle
I advocate for "Shared" (or something even better, if we'll find), since "Public" are most of tools that are on Toolserver...
Danny B.
------------ Původní zpráva ------------ Od: Krinkle krinklemail@gmail.com Předmět: Re: [Toolserver-l] Rename MMPs to "public tools" [was: Toolserver user phe account expired] Datum: 23.5.2012 20:49:30
On Wed, May 23, 2012 at 6:09 PM, Ilmari Karonen nospam@vyznev.net wrote:
On Tue, 2012-05-22 at 11:22 +0200, Merlijn van Deen wrote:
- easier creation of mmp's? I can imaging people don't move their
tools because it takes time to organise everything.
I hereby propose that we retire the term "multi-maintainer project" or "MMP", and just start calling them "public tools" (with an appropriate qualifier where necessary, as in "public tool account"), as opposed to "private tools" that run on users' personal accounts. I do realize that these names are not perfectly descriptive, but IMO they're at least better than what we have right now.
I agree with Ilmari.
Except I don't see the problem with the word "project" and "Public Tool Account" is asking for more scary abbreviations.
I'd recommend the name "Public projects" or "Shared projects" (instead of "Public tools"). Most accounts contain multiple tools. Since an MMP is just a shared account, it can perfectly contain multiple (related) scripts, or a framework, or collection of interconnected tools.
"Creating a public tool" (where one would previously say "Creating a MMP") sounds a bit off to me. "Creating a public project" or "Creating a shared project" sounds more natural to me.
Anyway, that's just terminology. I agree with Ilmari's reasoning.
-- Krinkle
On Wed, 2012-05-23 at 20:58 +0200, Danny B. wrote:
I advocate for "Shared" (or something even better, if we'll find), since "Public" are most of tools that are on Toolserver...
My point in suggesting "public" and "private" was to emphasize that the latter kind (which, indeed, currently make up the overwhelming majority, even if we'd like that to change) really do reside on the owner's private account, are maintained only by the owner and only survive as long as the owner keeps maintaining them (or at least keeps renewing their account). If the owner is run over by a bus, bye bye tool.
Ideally, I (and I assume others here) would like to see the "public" / "shared" / "multi-maintainer" tools to gradually become the default, unmarked case when someone speaks of a "Toolserver tool", with private tools becoming the ones that need a special qualifier. But this won't happen immediately, so for some time we're going to have to keep using qualifiers for both types of tools.
In this ideal world, most private tools would indeed be only private one-off tasks and development prototypes. Ultimately, I'd like to see tool authors routinely move any of their tools that seem useful to more than one person to a public account as soon as they're past the "alpha-testing" stage. But again, that will take some work, both in changing attitudes and in actually making the process easy enough for that to be practical.
Yeah, I guess I should start leading by example here. Now how did the current process for setting up an MMP, *ahem*, public tool go again...
On May 23, 2012, at 9:25 PM, Ilmari Karonen wrote:
On Wed, 2012-05-23 at 20:58 +0200, Danny B. wrote:
I advocate for "Shared" (or something even better, if we'll find), since "Public" are most of tools that are on Toolserver...
My point in suggesting "public" and "private" was to emphasize that the latter kind (which, indeed, currently make up the overwhelming majority, even if we'd like that to change) really do reside on the owner's private account, are maintained only by the owner and only survive as long as the owner keeps maintaining them [..]
Do note, however, that: * since a while now every account is required to set a default license for scripts in their home directory * in most cases (always?) ts-users can read files in other user's public_html directory. And some users open up "read" for the root of their home dir as well (I do), of course invidual files that are sensitive can (and should) be chmod'ed differently.
-- Krinkle
How do I find out what a particular account's default license is?
Ryan Kaldari
On Wed, May 23, 2012 at 1:51 PM, Krinkle krinklemail@gmail.com wrote:
On May 23, 2012, at 9:25 PM, Ilmari Karonen wrote:
On Wed, 2012-05-23 at 20:58 +0200, Danny B. wrote:
I advocate for "Shared" (or something even better, if we'll find),
since "Public" are most of tools that are on Toolserver...
My point in suggesting "public" and "private" was to emphasize that the latter kind (which, indeed, currently make up the overwhelming majority, even if we'd like that to change) really do reside on the owner's private account, are maintained only by the owner and only survive as long as the owner keeps maintaining them [..]
Do note, however, that:
- since a while now every account is required to set a default license for
scripts in their home directory
- in most cases (always?) ts-users can read files in other user's
public_html directory. And some users open up "read" for the root of their home dir as well (I do), of course invidual files that are sensitive can (and should) be chmod'ed differently.
-- Krinkle
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
On Wed, May 23, 2012 at 5:53 PM, Ryan Kaldari kaldari@gmail.com wrote:
How do I find out what a particular account's default license is?
Ryan Kaldari
$ ldapsearch -h ldap -b ou=people,o=unix,o=toolserver uid=UIDHERE tsDefaultLicense
toolserver-l@lists.wikimedia.org