Wikimedia Meta-Wiki

Requests for comment/Abandoned Labs tools

< Requests for comment

The following request for comments is closed. The results of the vote are as follows:

  • The proposal to enact the "Tool Labs right to fork policy" and form a committee to help oversee the policy. With 29 votes in favor and 2 votes against the proposal passes with a 93.54% approval.
  • The proposal to enact the "Tool Labs abandoned tool policy" and form a committee to help oversee the policy. With 19 votes in favor and 4 votes against, the proposal passes with 82.60% of approval.
The result of this RFC has been concluded using an objective measure: counting votes and calculating the support, so whist this user has voted in this RFC, the results are not altered. —MarcoAurelio 16:04, 11 December 2016 (UTC)[reply]

Rebooting this discussion with two concrete proposals

edit

The 2015 discussion of this topic stalled out without a useful policy and did not attract a large number of comments. Our on-wiki communities are still highly dependent on volunteer developed tools and vulnerable to disruption when the original developers move on. I have drafted two straw dog policies that attempt to define fair and workable solutions to the general problem. The proposals take two different but compatible approaches to solving the problem of abandonment. The Tool Labs developer community could choose to adopt either or both policies as protection for the communities that they serve.

The first policy describes a right to fork for all Tool Labs hosted software. This policy clarifies the existing Tool Labs Open Source and Open Data requirements and defines a process for requesting access to code and data that are not already published publicly.

The second policy is a more aggressive abandoned tool policy that describes a process for adding new maintainers to a tool account (adoption) with a future possibility of removing the original maintainers (usurpation). This policy is based primarily on the discussions that happened here on Meta in 2015.

Both policies propose creating a new committee of volunteers to evaluate requests and perform cleanup of sensitive data in the tool before providing the source code or direct access to the tool account. This provision is key to actually implementing both proposals. Paid administration and management does not scale any better than paid editing. To continue to grow and thrive, the Tool Labs developer community needs to become more active in enforcing and expanding their own policies. Membership in the committees would require signing the Wikimedia Foundation's Volunteer NDA to ensure that sensitive data is handled appropriately. If both polices are adopted the two committees should be collapsed into a single group with authority to handle both types of requests.

The straw dog policies are posted on Wikitech:

Discussion of the particulars of each proposal should happen on their associated talk pages. As an example it would be appropriate to debate whether the 14 day non-functional waiting period is too short or too long on the Abandoned tool policy talk page. Discussion of the process in general can happen here on Meta. I will also announce the discussion on wikitech-l and Phabricator, so some discussion may end up in those locations as well. I will however try to funnel the various discussions towards this page and the proposal talk pages.

I would like discussion to remain open through 2016-10-12 (3 weeks from date of posting). Following the discussion period I hope to call for an approval vote of some sort to make the policies official. Wikitech and Tool Labs do not currently have well defined policies for establishing consensus, but I'm sure we can collectively come up with something reasonable.

--BDavis (WMF) (talk) 21:23, 21 September 2016 (UTC)[reply]

The arbitrary 2016-10-12 discussion deadline has passed and posts here and on the respective policy talk pages has died down. I'm marking this round of discussion here and on the Wikitech talk pages as closed. The next step is for me to revise the straw dog proposals based on the input that has been given and then call for a vote to approve or reject the new policies. --BDavis (WMF) (talk) 23:55, 17 October 2016 (UTC)[reply]

Call for vote on straw dog proposals

edit

I (BDavis) would like the Tool Labs community to determine if one or both proposed policies should be adopted before attempting to define the specifics of membership and operation of the committee called for by either policy. If both policies are approved it seems logical to combine the two committees into one body. If one or both policies have consensus, then we can open a brief follow up discussion to decide how to bootstrap the committee.

Question 1: adopt Right to fork policy

edit

The Tool Labs community should adopt the "Tool Labs right to fork policy" and form a committee to help oversee the policy.

Yes
  1. Support Support BDavis (WMF) (talk) 01:38, 20 November 2016 (UTC)[reply]
  2. Support Support in principle, on the expectation that we discuss afterwards how committee membership will be determined, and the result of that discussion is written into the committee section of the policy. --Krenair (talk • contribs) 02:02, 20 November 2016 (UTC)[reply]
  3. Support Support Clear cut. --QEDK (talk) 07:32, 20 November 2016 (UTC)[reply]
  4. Support Support --Zhuyifei1999 (talk) 09:41, 20 November 2016 (UTC)[reply]
  5. Support Support --Ricordisamoa 13:09, 20 November 2016 (UTC)[reply]
  6. Support Support in general; I have many doubts about a committee trying to publish foreign source code in a (re-)useful way, and I fear that the request mechanism will be used to make developers jump through hoops by people not actually interested in contributing. I would prefer if all requests need to go through the committee, so it can filter out non-productive behaviour. But on balance, I think this policy brings more good than bad. --Tim Landscheidt (talk) 14:25, 20 November 2016 (UTC)[reply]
  7. Support Support I was not aware that such policy exists until today (shame), but I myself have put the source code of my active tools on GitHub already, and I think it is the move in the right direction if we expect of all of our contributors to do the same. Huji (talk) 15:42, 20 November 2016 (UTC)[reply]
  8. It's ok to force FLOSS licenses. The rest of the policy is quite soft anyway, but having a process to distribute code is good. --Nemo 20:04, 20 November 2016 (UTC)[reply]
  9. Support Support We don't allow copyrighted content on Commons, why allowing it here? Le Loy 00:36, 21 November 2016 (UTC)[reply]
  10. Support Support The only hard requirement here is that a tool must be licensed under an appropriate software license, which mirrors the requirements we already have for contributions to the projects. If people want to run a closed-source tool, they're welcome to host it elsewhere. While there's a potential for concern over source code for certain anti-vandalism bots' functions, I also note that the policy doesn't require all requests for source be granted. Anomie (talk) 15:20, 21 November 2016 (UTC)[reply]
  11. Support Support This is the stick, we should also work on a carrot for maintainers who implemented all requirements. Multichill (talk) 15:57, 21 November 2016 (UTC)[reply]
  12. Support Support MichaelSchoenitzer (talk) 21:11, 21 November 2016 (UTC)[reply]
  13. Support Support - Husky (talk) 10:10, 22 November 2016 (UTC)[reply]
  14. Support Support Jean-Fred (talk) 12:07, 22 November 2016 (UTC)[reply]
  15. Support Support Legoktm (talk) 19:31, 22 November 2016 (UTC)[reply]
  16. Support Support — MusikAnimal talk 23:42, 22 November 2016 (UTC)[reply]
  17. Support Support --Waldir (talk) 14:05, 23 November 2016 (UTC)[reply]
  18. Support Support Andrewbogott (talk) 16:29, 23 November 2016 (UTC) This strikes me as a clarification and implementation process for the existing Labs terms of use. Labs already requires that new code be open source.[reply]
  19. Support Support - This has to be recognized to ensure the stability of Tools as an ecosystem. CPettet (WMF) (talk) 16:34, 23 November 2016 (UTC)[reply]
  20. Support Support I would also make the publication of the source code mandatory from the start, to make the transition less painful. --Pietrodn · talk with me 09:53, 25 November 2016 (UTC)[reply]
  21. Support Support —MisterSynergy (talk) 20:34, 25 November 2016 (UTC)[reply]
  22. Support Support --Tgr (talk) 09:43, 27 November 2016 (UTC)[reply]
  23. Support Support Nux (talk) 22:51, 27 November 2016 (UTC) forking right seems obvious consequence once you have an OSI license, but if you think a policy is required to make things clear then it's fine.[reply]
  24. Support Support JAn Dudík (talk) 21:20, 28 November 2016 (UTC)[reply]
  25. Support Support PKM (talk) 21:49, 28 November 2016 (UTC)[reply]
  26. Support Support A process to distribute code is necessary. Sumita Roy Dutta (talk) 08:49, 29 November 2016 (UTC)[reply]
  27. Support Support — xaosflux Talk 18:12, 29 November 2016 (UTC)[reply]
  28. Support Support — RandomDSdevel (talk) 21:39, 29 November 2016 (UTC)[reply]
  29. Support Support Provides some pointers in the right direction while not being too strict. Linking to some examples of good practice could help newcomers who might find this a little daunting. Danmichaelo (talk) 23:16, 4 December 2016 (UTC)[reply]
No
  1. Oppose Oppose I do not feel confortable with licensing and making code public even if the mantainer don't want to. If it is their creation, it's their choice to decide what to do with the work, whether to publish it or not and under which conditions. —MarcoAurelio 15:48, 20 November 2016 (UTC)[reply]
  2. Oppose Oppose Requiring OSI license shuts out frameworks like React framework. Also, Forking is useless if dependent on third party services, such as with CorenSearchBot. Dispenser (talk) 19:02, 22 November 2016 (UTC)[reply]
    IIUC OSI licenses are already required in the Tool Labs ToS. This proposal only defines a process for forking tools that should already be FOSS, so opposition to the use of OSI licenses shouldn't influence the outcome of this RfC. --Waldir (talk) 14:05, 23 November 2016 (UTC)[reply]
    We are currently in talks with the legal side of WMF because of the React licensing. The Terms Of Use currently states:
    Tool Labs projects must be open source software licensed under an OSI approved license This is not a component as of this proposal as it is an existing requirement.
    -- CPettet (WMF) (talk) 16:29, 23 November 2016 (UTC)[reply]

Question 2: adopt Abandoned tool policy

edit

The Tool Labs community should adopt the "Tool Labs abandoned tool policy" and form a committee to help oversee the policy.

Yes
  1. Support Support BDavis (WMF) (talk) 01:38, 20 November 2016 (UTC)[reply]
  2. Support Support same as above. --Krenair (talk • contribs) 02:02, 20 November 2016 (UTC)[reply]
  3. Support Support --QEDK (talk) 07:32, 20 November 2016 (UTC)[reply]
  4. Support Support but more clarification needed on the scope (is it only tool labs?) and process of handling cross-project tools (half-tool-labs half-in-other-labs-project tools (eg. video2commons)) --Zhuyifei1999 (talk) 09:41, 20 November 2016 (UTC)[reply]
  5. Support Support; I think the criteria are much too high for real-life tools (at least 14 days nonfunctional), but given that adoption of tools has been stalled by not having a policy now for over a year, two weeks is better than eternity. --Tim Landscheidt (talk) 14:33, 20 November 2016 (UTC)[reply]
  6. Support Support although I think the criteria is too strict. Our contributors are volunteers, so expectations should be set accordingly. That being said, the lack of such policy enforcement has resulted in lots of nonfunctional tools abandoned for long periods of time; at least the policy sets the stage for how we are going to mitigate them. Huji (talk) 15:44, 20 November 2016 (UTC)[reply]
  7. Adoption is good, while I'm not sure what's the point of removing an entirely inactive user (unless there are security concerns). Either way, this proposal is very cautious. --Nemo 20:04, 20 November 2016 (UTC)[reply]
  8. Support Support, I say, we have to allow usurping inactive tools if there's a bug that hasn't been fixed/commented by active maintainers for 3 months :D Just joking. But this proposal is a good start. Le Loy 00:36, 21 November 2016 (UTC)[reply]
  9. Support Support I think adoption/usurpation is important as a possibility for webservice tools, and the policy written provides adequate safeguards, e.g. removal of credentials or community approval before adoption and a contact requirement with a defined time to reply. And I note that the policy as written does not require the committee actually grant any particular adoption or usurpation request. Anomie (talk) 15:20, 21 November 2016 (UTC)[reply]
  10. Support Support Legoktm (talk) 19:32, 22 November 2016 (UTC)[reply]
  11. Support Support Usurping/adoption is important when there are hundreds to thousands of links to what was a working tool — MusikAnimal talk 19:57, 22 November 2016 (UTC)[reply]
  12. Support Support The various conditions provide good protection against abuse of this process, and ensure that the adoption and/or usurpation results in not only a restored tool, but one that is better prepared to remain maintained into the future (e.g. multiple maintainers, public source code, etc., which for unusurped tools is only recommended, not enforced). --Waldir (talk) 14:13, 23 November 2016 (UTC)[reply]
  13. Support Support Every responsible project has a contingency plan for what to do if a developer is run over by a bus. Andrewbogott (talk) 16:35, 23 November 2016 (UTC)[reply]
  14. Support Support This formalizes a process we are already forced to do on occasion. The setting of expectations in an explicit manner so new developers are empowered to stand on the shoulders of those who have left, and so that services that have become loved and necessary can continue to function is a needed thing. CPettet (WMF) (talk) 16:39, 23 November 2016 (UTC)[reply]
  15. Support Support —MisterSynergy (talk) 20:34, 25 November 2016 (UTC)[reply]
  16. Support Support --Tgr (talk) 09:51, 27 November 2016 (UTC)[reply]
  17. Support Support PKM (talk) 21:50, 28 November 2016 (UTC)[reply]
  18. Support Support — RandomDSdevel (talk) 21:41, 29 November 2016 (UTC)[reply]
  19. Support Support Tool Labs improved upon Toolserver in that it made tools a little less dependent on a single user. This is another step in the right direction imho. Danmichaelo (talk) 23:16, 4 December 2016 (UTC)[reply]
No
  1. I'm sorry but I Oppose Oppose the usurpation part --Ricordisamoa 13:06, 20 November 2016 (UTC)[reply]
  2. Oppose Oppose unless opt-out of usurpation is allowed. —MarcoAurelio 15:52, 20 November 2016 (UTC)[reply]
  3. Oppose Oppose - i agree with the sentiment, but i believe that this policy will lead to too much policing and might scare off new volunteers. Husky (talk) 10:13, 22 November 2016 (UTC)[reply]
  4. Oppose Oppose The time limits are too short IMO. --Pietrodn · talk with me 09:56, 25 November 2016 (UTC)[reply]

2015 discussion

edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

Per Phab:T87730 I'm starting a discussion on creating a process for usurping or otherwise being added as a maintainer to existing tools which appear to be abandoned.

Pinging coren, Cyberpower678, Zhaofeng Li, MusikAnimal, LuisV (WMF), yuvipanda - {{U|Technical 13}} (e • t • c) 22:29, 11 February 2015 (UTC)[reply]

In particular, the following three questions need some consideration:

  1. Under what criteria are tools considered "abandoned" and subject to being handed to someone else?
  2. To whom are abandoned tools handed over?
  3. What happens to credentials a tool may hold (for instance, bot accounts, OAUTH secrets, etc).

Those three points seem the most salient to me, but I have no doubt more exist. MPelletier (WMF) (talk) 23:55, 11 February 2015 (UTC)[reply]

Just my two cents:
  1. Under what criteria are tools considered "abandoned" and subject to being handed to someone else?
    1. For usurpation:
      • The tool has been nonfunctional for 180 days (when a notice will be sent to the owner) AND
      • The tool owner hasn't been active in any Wikimedia project for 60 days AND
      • The tool owner has been notified and has not objected to the usurpation within 10 days from the notification
    2. For maintainer addition:
      • The tool has been nonfunctional for 60 days (when a notice will be sent to the owner) AND
      • The tool owner hasn't been active in any Wikimedia project for 30 days AND
      • The tool owner has been notified and has not objected to the addition within 10 days from the notification
  2. To whom are abandoned tools handed over?
    • The tools will be handed over to users who
      1. has requested to usurp the tool or be added to the maintainer list AND
      2. has demonstrated their skills required for maintaining the tool AND
      3. is in good standing within the community
  3. What happens to credentials a tool may hold (for instance, bot accounts, OAUTH secrets, etc).
    • For both usurpation and (forced) maintainer addition:
      1. All credentials will be removed prior to the hand-over, which will be done by WMF employees
      2. Bots will be subject to a review in the local communities to demonstrate their trust in the new maintainer, after which bot account access will be restored
Zhaofeng Li [talk... contribs...] 05:19, 12 February 2015 (UTC)[reply]
Pretty strict, but I think it's the best way to avoid conflicts. Zhaofeng Li [talk... contribs...] 05:22, 12 February 2015 (UTC)[reply]
  • Do the benefits of allowing people to take over tools outweigh the potential conflict should original maintainers return? In particular, is it infeasible for people who want to maintain an abandoned tool to just fork it and ask projects to point any links to the maintained version instead (and perhaps ask Labs admins to place a link to it on the old version)? I'm uncomfortable with a system where people can take over control to software originally maintained by others; the FOSS norm of forking seems to have worked fine elsewhere, and carries fewer risks. wctaiwan (talk) 17:52, 12 February 2015 (UTC)[reply]
Forking can be very time-consuming, as many of the tools are not build with the requirement in mind that they should be. They are mostly build by only one person, grown over time and sparsely documented at best. Their source code might not be published at all, in its entirety, the up-to-date version, or with instructions on how to set it up and which additional libraries are needed. Being able to obtain the previous working setup, fix whatever is broken and hit the restart button is much easier.
I would differentiate if the goal of the new maintainer is to fix a non-functional tool or to do major changes to it. I don't see many devs objecting if someone trustworthy takes the time to fix the tool they have gifted to the world. I do not support usurpation, only maintainer addition. --Sitic (talk) 20:44, 12 February 2015 (UTC)[reply]
I'm confident that the author and the users of derivativeFX will support any working solution. –Be..anyone (talk) 02:02, 17 February 2015 (UTC)[reply]
I'm confident that the author and the users of SVG Check will support any working solution. –Be..anyone (talk) 23:32, 17 February 2015 (UTC)[reply]
  • In general, I support this proposal. I think it would benefit from additional clarification. What does "notification" comprise, specifically? And what does "non-functional" mean, specifically? I can think of a specific case, Citation Bot on en.WP, where the tool functions as programmed, but has bugs, as all complex software does. Does "non-functional" include the state in which bugs have been reported but the maintainer has not attempted to fix them? I would think that adding a maintainer, rather than usurping, would be a reasonable course of action in that case. Jonesey95 (talk) 05:03, 17 February 2015 (UTC)[reply]
  • There can be problems with "The tool owner hasn't been active in any Wikimedia project for 60 days". One can be active in some local project but not willing (or not able) to maintain and update his tools on ToolLabs. --Infovarius (talk) 09:34, 17 February 2015 (UTC)[reply]
  • I agree and think it should be an OR instead of an AND for nonfunctional/inactive on any project. I also think that waiting over six months for a tool is unacceptable. Here are my thoughts on it:
  1. Under what criteria are tools considered "abandoned" and subject to being handed to someone else?
    1. For maintainer addition:
      • The tool has been nonfunctional (no webservice/offline) for 15 days OR
      • The tool owner hasn't been active in any Wikimedia project for 31 days AND
      • The tool owner has been notified via talk page post on their home wiki and email (if available) and has not objected to the addition within 15 days from the notification
    2. For usurpation:
      • The requesting usurper has been added as a maintainer per above AND
      • It has been 250 days since the tool went from nonfunctional to functional AND
        280 days minimum from start of process
      • The tool owner has been notified via talk page post on their home wiki and email (if available) and has not objected to the usurpation within 91 days from the notification
    Total minimum time for usurpation process: little over 1 year (370 days)
  2. To whom are abandoned tools handed over?
    • The tools will be handed over to users who...
      1. ...have requested to be added to the maintainer list or to usurp the tool AND
      2. ...have demonstrated their skills required for maintaining the tool AND
      3. ...are in good standing within the labs community
  3. What happens to credentials a tool may hold (for instance, bot accounts, OAUTH secrets, etc).
    • All new maintainers will be subject to a review in the local communities to field objections and questions prior to any action being taken
    • For (forced) maintainer addition, credentials may be removed prior to the hand-over, at the discretion of WMF employees under advisement of the communities served
I think that getting maintainers added is a much more critical priority, and we shouldn't wait long there since there are tools that are critical to improvement of pages and extended downtime could be extremely disruptive to the communities using them. I think that the 250 day period to get the tool back up should be plenty of time for a user to demonstrate they are capable and have the time to devote to keeping the tool/bot running. I think that all tool maintainers should also take away from this discussion that it would be wise for them to choose additional people they trust to maintain their tool if they suddenly become unavailable for whatever reason instead of leaving the community in a position to have to actually use this process. :D - {{U|Technical 13}} (e • t • c) 15:23, 17 February 2015 (UTC)[reply]
Excellent suggestion, tools with only one active maintainer SHOULD NOT be hosted on toollabs:, this environment is apparently far too fragile needing manual interventions far too often. –Be..anyone (talk) 23:45, 17 February 2015 (UTC)[reply]
Um, maybe there is no point in removing the original owner (usurpation) after all. Does having an inactive maintainer in the access list pose any problem at all? Zhaofeng Li [talk... contribs...] 07:03, 19 February 2015 (UTC)[reply]
  • That depends on how much woek the new maintainer put into the tool. If the new maintainer has virtually rewritten the entire tool during the year they would have to wait to usurp it, what actual benefit is there to leaving the extra name on the maintainer list? I could see certain people come back agter years of being away and seeing their tool not existing in a form anywhere near where they left it reverting it to what it was years ago and having communities upset about the loss of feature X, Y, or Z. I'm sure most people who might usurp a tool would be happy to add the original programer back upon request after catching them up on and making sure they are cool with the changes. - {{U|Technical 13}} (e • t • c) 12:50, 19 February 2015 (UTC)[reply]
  • Another question that hasn't been asked on here that should be addressed is "How should requests be submitted?" A ticket on Phabricator? A casual request via IRC either in the #wikimedia-labs channel or via PM to a labs admin? On an labs admin's talk page? Via a special interface like OTRS/UTRS/ACC? All of the above? None of the above? - {{U|Technical 13}} (e • t • c) 02:04, 19 February 2015 (UTC)[reply]
phabricator: sounds good, somebody without phabricator: account (like me at the moment) has no business on toollabs:. –Be..anyone (talk) 03:15, 19 February 2015 (UTC)[reply]
@Be..anyone: You don't need a separate account, just log in with your SUL account. And I have to disagree with your view that only people who "has business on toollabs:" can participate. Since users are the ones who make use of the tools, we should respect them and make the process as accessible as possible. Also, such requests should be formal and recorded, since credentials and other confidential information are involved. In my opinion:
  • for cross-wiki web-based tools/bots: A RfC-like process will be held on Meta. Notifications will be shown on the proper discussion pages on local wikis (e.g. Technical Village Pump on enwiki). For web-based tools, a WMF employee will temporarily replace the tool's web interface into a link to the discussion page (as the tool is already down).
  • for web-based tools/bots that only work on a single wiki: A RfC-like process will be held on the wiki it's supposed to work on. Notifications will be shown on the proper discussion pages on that wiki. For web-based tools, a WMF employee will temporarily replace the tool's web interface into a link to the discussion page (as the tool is already down).
I need to stress that such procedure should only be used as a last resort, when no alternative solution exist.
Zhaofeng Li [talk... contribs...] 07:24, 19 February 2015 (UTC)[reply]
For that matter, if we're going to do it on Phab and everyone with an SUL has Phab access, I'd say have the discussion right in the ticket with notices about the discussion going in wikitech-l, labs-l, and the tech-news on wiki newsletter that is translated and spread to most of the "appropriate" places on global wikis. If it is a tool/bot localized to one wiki, then wikitech-l, labs-l, tech-ambassador, and the appropriate onwiki forum(s). - {{U|Technical 13}} (e • t • c) 12:55, 19 February 2015 (UTC)[reply]
The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.


2016 discussion

edit
The following discussion is closed. Please do not modify it. Subsequent comments should be made in a new section.

What specifically is "critical"?

edit

wikitech:Help:Tool Labs/Right to fork policy and wikitech:Help:Tool Labs/Abandoned tool policy refer to critical tools and/or critical functionality. What critical tools and functionalities are being referred to? I thought we had a pretty clear policy that anything truly important ("critical") wasn't hosted on Wikimedia Labs, Tool or otherwise. --MZMcBride (talk) 03:08, 22 September 2016 (UTC)[reply]

Legoktm updated the Right to fork policy to say "useful" instead of "critical" and I made a matching change to the Abandoned tool policy. Personally I think this is an inconsequential distinction. At the most pedantic level, the data held in the wikis may be the only critical infrastructure of the movement, but I'm fairly confident that if all of the tools and bots hosted in Tool Labs disappeared that many content curation workflows would be heavily impacted. --BDavis (WMF) (talk) 14:39, 22 September 2016 (UTC)[reply]

Discussion too fragmented

edit

As was raised last year, I think the discussion has too many places where it can occur. I suggest clearly closing down the talk pages on Wikitech by adding redirects and make a choice between whether discussions should be on Phabricator tasks or here. I would like to add a view on waiting times, but the discussion above looks stale. --Fæ (talk) 07:33, 22 September 2016 (UTC)[reply]

I struggled to determine where discussion could/would happen. Currently the talk page of the Right to fork policy is getting the most activity and constructive suggestions. I personally find the single linear organization of a Phabricator task discussion to be too restrictive for a discussion of this complexity. Finding the right place to talk with Tool Labs maintainers in general has been difficult as few of them seem to congregate in any one forum as a cohesive group.

I would like to add a view on waiting times, but the discussion above looks stale.

I tried to specifically address this in my reboot announcement:

Discussion of the particulars of each proposal should happen on their associated talk pages. As an example it would be appropriate to debate whether the 14 day non-functional waiting period is too short or too long on the Abandoned tool policy talk page. Discussion of the process in general can happen here on Meta.

--BDavis (WMF) (talk) 14:55, 22 September 2016 (UTC)[reply]

Committee membership

edit

I note neither draft currently attempts to define how members of the committee are chosen from among those applicants who meet the qualifications, how many members the committee should have, or what length of term they serve for. That's not hugely important for the current point in the discussion, but will be needed once you get to the point of actually proposing these for approval. Anomie (talk) 15:01, 22 September 2016 (UTC)[reply]

Require open-source

edit

I believe the best solution to a lot of interconnected problems is a requirement to release tools as open-source. Creating forks would be a no-brainer. Also it complies nicely with the whole free knowledge idea behind the Wikipedia etc. Le Loy 00:49, 26 September 2016 (UTC)[reply]

This is basically the focus of the Tool Labs right to fork policy. As discussed on the policy talk page, Open Source and Open Data have been part of the Labs terms of use since at least 2012-03-20T18:55:06. Sadly there has not historically been a procedure for enforcing compliance. I feel that the right to fork policy and especially the committee it would establish is a reasonable means to promote Open Source/Open Data compliance by Tool maintainers and to provide a means for enforcement. --BDavis (WMF) (talk) 01:36, 26 September 2016 (UTC)[reply]
I also like the idea of a requirement for release of the source code under free license in Wikimedia's provided version control system. It also would be nice if all the tools used the same license so it is easier to share code. Than Right_to_fork_policy would not be necessary at all. We only would need policy for making sure that we do not have several forks of the same code competing with each other. I write a lot of templates and LUA tools on Commons. All the code by being on the project is released under open-license and page history serves well as a version control. If I stop maintaining the codes I wrote anybody can began maintaining them, without any Right_to_fork or Usurpation policy. --Jarekt (talk) 18:40, 26 September 2016 (UTC)[reply]
In this sentence: "All Tool Labs hosted tools should publish their source code using Wikimedia's provided version control services, another public version control system, or some other publicly accessible means." I would change 'should' to 'must'. This isn't just right to fork, it's simple maintenance. Tool maintainers get bored, move on to other things, have family obligations, or even depart this life, and without source code the tool will die too. -- ArielGlenn (talk) 20:10, 3 October 2016 (UTC)[reply]

It also would be nice if all the tools used the same license so it is easier to share code.

This would be hard to do in a practical way. The FLOSS licensing world is fragmented and a number of licenses are incompatible with each other. The easiest example of this is the unidirectional compatibility of the GPL and MIT licenses. You can generally take MIT code and add it to a GPL licensed project, but you can't incorporate the resulting source in another MIT licensed project without violating the GPL. We could certainly promote the choice of a narrow set of licenses for new projects, but there are likely to be many Tools that use 3rd party FLOSS source that would not be able to be re-licensed to an arbitrary license chosen to cover everything. --BDavis (WMF) (talk) 18:56, 26 September 2016 (UTC)[reply]

Free license requirement I'm surprised this isn't true already, actually. We can simply offer a suite of acceptable licenses, just like at (e.g.) c:COMM:License and then make source available to anyone for forking/usurping/etc. —Justin (koavf)❤T☮C☺M☯ 03:31, 8 October 2016 (UTC)[reply]

The above discussion is preserved as an archive. Please do not modify it. Subsequent comments should be made in a new section.
Retrieved from "https://meta.wikimedia.org/w/index.php?title=Requests_for_comment/Abandoned_Labs_tools&oldid=21696419"