Wikimedia Foundation Board noticeboard

From Meta, a Wikimedia project coordination wiki
(Redirected from Board noticeboard)
Jump to: navigation, search
Board of Trustees Board noticeboard Archives
Welcome to the Board of Trustees' noticeboard. This is a message board for discussing issues related to Wikimedia Foundation governance and policies, and related Board work. Please post messages at the bottom of the page and sign them.
  • For details on the Board's role and processes, see the board manual.
  • This page is automatically archived by MiszaBot. Threads older than 90 days will be moved to the archive.

Discussion on Commons and URAA[edit]

Further to our letter regarding the deletion of images from Commons under URAA, we would love to see this subject discussed in the upcoming board meeting. • Yael Meron (WMIL) • 11:01, 6 February 2014 (UTC)

We did discuss it at the (past) board meeting, thank you Yael. A response from the Board will be coming within the next week. SJ talk  02:20, 8 February 2014 (UTC)
reply is now here. -- phoebe | talk 19:42, 20 February 2014 (UTC)

Have you seen how Yann closed the "discussion" on commons:Commons:Massive restoration of deleted images by the URAA?

Yes check.svg Closed as YES. URAA cannot be used as the sole reason for deletion. Deleted files can be restored after a discussion in COM:UDR. Potentially URAA-affected files should be tagged with {{Not-PD-US-URAA}}. Yann (talk) 10:17, 2 April 2014 (UTC)

It seems to me that he must have missed the text "and remove works that are clearly infringing" in this sentence from Legal and Community Advocacy/URAA Statement:

The community should evaluate each potentially affected work using the guidelines issued by the Legal and Community Advocacy Department, as well as the language of the statute itself, and remove works that are clearly infringing.

SamB (talk) 21:52, 4 April 2014 (UTC)

As we said in our statement, "We are not recommending that community members undertake mass deletion of existing content on URAA grounds". Additionally, there is a newer statement than the one you quoted from Legal here that reiterates the point that "WMF does not see a reason to delete content simply because of general concern about the URAA". Yann's closure seems consistent with that principle. -- phoebe | talk 21:29, 15 April 2014 (UTC)
@Phoebe: But Yann seems to be saying we should NEVER delete things just because the URAA has restored their copyright. Isn't that illegal? Are you saying it's okay to break the law? —SamB (talk) 21:53, 15 April 2014 (UTC)
@SamB: hey, I interpreted that as him saying that *concern over potential URAA violation* shouldn't be used as the sole reason to delete stuff, which makes sense -- i.e. just flagging it as potentially URAA-incompatible shouldn't be enough to trigger deletion, which can be quite a disruptive action. URAA is complex, and I am saying preemptive actions (like preemptive deletion) don't seem necessary. It would be worth clarifying on-wiki with Yann if you have concerns about what he was saying, however. -- phoebe | talk 20:13, 16 April 2014 (UTC)
Hi phoebe, I had previously read the WMF statement as not being advice to Commons project administrators. Is the WMF board advising Commons administrators that they can safely refuse to delete URAA breaching material from Commons and can safely undelete images previously deleted on the basis of URAA violations? If so, then this would be a helpful clarification as many contributors seem to read it as a directive and as a result expect and require Commons administrators to take action accordingly. -- (talk) 20:28, 16 April 2014 (UTC)

Resolution specific licensing[edit]

We failed to arrive in a conclusion on how to handle cases when a user grant a free license to a limited size version expecting that he still can sell his original high resolution work to make money. We discussed it in detail here, consulted CC and WMF legal; but still struggling to make a concrete decision. Earlier we all thought that a license is applicable for what is shared there; not applicable to a large size version of it even if found elsewhere. The WMDE community had collected 80,000+ files from Bundesarchiv on this assumption. CC's new comments muddled the situation; but still the relevant copyright law is not clear. So what we have to do now. Please advise. (The summary of that discussion is available here.) Jee 05:10, 24 February 2014 (UTC)

This is a good question. I think a fair solution would be to set Commons & community policy on the matter: deciding what our social norm will be. We can explain our community's interpretation of the CC licenses when we discuss with potential grantors. We should also explain to them that there is some disagreement about how to interpret the license; and that in some jurisdictions granting a CC license on a low-res copy may implicitly grant a license in the high-res copy. This hypothetical has not been tested. For the record, I think that the uncertainty alone will be incentive enough for anyone with the budget to pay for a high-res license to do so.
In the spirit of honoring our community's agreements, my personal view is that our projects should not incorporate high-res images where low-resolution versions have been donated under a CC license to benefit our projects, through an agreement with community curators that implied that low-resolution and high-resolution images could be licensed separately, with only low-resolution versions released under a free license. This would change as soon as higher-resolution versions are made similarly available. So for the Bundesarchiv photos, we should remove high-res images unless the archiv donates those explicitly makes those explicitly available under a free license.
I believe all of this can be resolved by the Commons community. SJ talk  06:08, 24 February 2014 (UTC)
Thanks Sj for your opinion. Jee 06:29, 24 February 2014 (UTC)
Very reasonable approach, @Sj at least for things that are covered by copyright. That neatly avoids the need for fancy legal footwork, speculation, etc. I strongly support that approach. (Though I think you mean, "made available under a free license" rather than "donated to us, no?) In a similar case where, for instance, a GLAM donates low-res versions of a public domain image, and then somebody acquires higher resolution versions in any way, it seems fine to upload them over the low-res versions. -Pete F (talk) 21:54, 15 April 2014 (UTC)
It is the norm for those of us managing partnerships with GLAM and helping GLAMs to get Wikimedia related projects funded to avoid promising to only upload limited resolution images when higher versions are available as this is neither a particularly desirable outcome for our mission to preserve human knowledge, nor can we stop volunteers from uploading higher resolution material (whether PD, CC0 or other license), and gives the impression that there are ethical and realistic remunerative reasons for GLAMs to use Commons as a way of promoting their on-line retail business which charges the public for higher resolution versions. If we really wanted to allow this, then we should enable Commons as a front-end for Getty Images as this perfectly fits the same world-view.
This has been thrashed out in the past, so I would rather any detailed discussion be held on Commons where others might notice and contribute rather than on meta with our limited community here. -- (talk) 12:57, 16 April 2014 (UTC)
+1 Fae, plus we should mention that this isn't within the remit of the Board, because it is judgement on how our projects manage their content. Russavia (talk) 13:02, 16 April 2014 (UTC)
True. My good faith assumption was that SJ was not speaking here as a WMF Trustee, but as a regular Commons contributor. It would be good to have the ambiguity removed so we avoid the words of SJ being misrepresented in another place. -- (talk) 13:12, 16 April 2014 (UTC)
Pete: I clarified my comment, thank you. Fae: Thanks for pointing out the recent norms of working with media partners.
As I said above, I believe all of this can (and should) be resolved by the Commons community. Let's have any further discussion there. Regards, SJ talk  21:44, 17 April 2014 (UTC)

Bitcoin Donations[edit]

Will the topic of Bitcoin donations be discussed at the upcoming April meeting? Note, I'm asking out of curiosity, not advocacy. -- Seth Finkelstein (talk) 14:01, 20 April 2014 (UTC)

This isn't a Board-level decision. Our fundraising team decides how and what payment methods to accept. I'm sure we will one day have a cleaner process for accepting and auto-converting donations in bitcoin (possible since 2012 via bitpay). SJ talk  19:02, 21 May 2014 (UTC)

Board agenda and minutes[edit]

Dear Board members or @Slaporte (WMF):

Please update Board meetings#2014 with the proposed agenda from here and please update WMF Board meetings/2014-01-31 with the completed minutes from here.

Please remember to make updates to the relevant Meta pages each time that you announce agendas or minutes.


--Pine 07:06, 22 April 2014 (UTC)

I guess the board doesn't do a very good job monitoring this board, since Board meetings#2014 was never updated until after the last meeting.--Elvey (talk) 06:48, 6 May 2014 (UTC)
I know our secretary does try to do this. Please feel free to update pages that you notice are lagging, at least with a link to the wmfwiki page (until the day that we merge that wiki into Meta!) SJ talk  19:05, 21 May 2014 (UTC)
Hi Sj, I thought the whole point of removing volunteer admin bits from the WMF wiki was that WMF felt that community admins were being obstructionist so the way to deal with that was to remove all volunteer admin flags on WMF wiki. Wouldn't merging WMF wiki into Meta wiki re-create the same problems that WMF decided were unacceptable on WMF wiki? --Pine 06:32, 22 May 2014 (UTC)
Hello Pine, I don't know what the point of removing those admin bits was; but as far as I can see it was a rough effort to ensure that certain protected pages, such as the main page, were only changed by staff. There was also a slow flame war between the WMF staff member responsible for that wiki and the most active non-staff admin; since the community there was so small, there weren't enough disinterested observers to moderate or cool down that tension. There are more subtle ways to bring about the same result: e.g., a simple policy about pages in a WMF Portal (e.g.: they should only be changed by staff). While there would be some merge-overhead, the current WMFwiki suffers from much more serious problems -- staleness, lack of synchronization with Meta, lack of transclusion and template sharing with Meta, difficulty interacting with translators. SJ talk  14:07, 24 May 2014 (UTC)
By the way, I don't mean that we should get rid of the wmfwiki: a brief summary of the organization and its current work, are well suited to being showcased with a separate logo, navigation bar, and recentchanges. Most entities in our movement have their own site for this. ( I think a better long-term solution is to implement subsites/subwikis, making this sort of customization possible. But that's a different matter. ) But most of the current WMFwiki pages -- resolutions, minutes, meetings, press releases, detailed userpages, &c -- are better suited to meta. Any page that needs constant updating, or whose updating should trigger an update on Meta, likely belongs here in the first place. SJ talk  14:37, 24 May 2014 (UTC)
Thanks, I understand. --Pine 07:26, 25 May 2014 (UTC)

Privacy Policy — Information We Collect : proposed disclosure is misleadingly incomplete[edit]

The Privacy Policy was discussed at the board meeting last week. I pushed for and gained consensus for language in the new policy that made it clear that the privacy policy would not allow browser sniffing. It was added back in December when this was discussed AT LENGTH at Talk:Privacy_policy/Archives/2013_(2)#Information_We_Collect:_proposed_disclosure_is_misleadingly_incomplete and stayed in the draft for weeks. Then on the last day, it was removed. Now we have a draft privacy policy that does not bar browser sniffing, does not indicate that browser sniffing may take place and yet claims to be maximally informative. That's an untenable situation. That's the bottom line. I've complained about this as Talk:Privacy_policy when I noticed it, and was ignored. I hope the board adopts a new policy that is not misleadingly incomplete. Be honest. --Elvey (talk) 06:48, 6 May 2014 (UTC) (Bump. Hello?) 20:57, 10 May 2014 (UTC))

Belated clarification: I'm talking about the practice of browser sniffing to uniquely identify a reader by collecting as much information about the browser as possible including plugins and fonts. I'm not talking about simple browser sniffing to counteract user agent spoofing or even simpler straightforward use of the User-Agent string (of § 14.43 of RFC 2616/HTTP/1.1).--Elvey (talk) 18:27, 21 May 2014 (UTC)
I'm not sure how you interpret "maximally informative" here. You mean you'd like to see a sentence specifically addressing browser sniffing, or pointing to an FAQ that describes what sorts of browser sniffing may happen and how the resulting information is treated? There is a related section at Talk:Privacy policy (which section should probably be renamed). SJ talk  19:13, 21 May 2014 (UTC)
Sj: Yes, yes. I'm not saying we/you can't revoke the commitment Drdee gave, that browser fingerprinting is incompatible with this Policy. I'm saying that after having read the policy and FAQ, a user should know what browser fingerprinting is (via a link, perhaps), know that WM employs it, and that access is restricted to approved projects and user groups X, Y, Z, only (link to list of existing pages on them ), ... Make sense? I can create a version with suggested edits, AND I'd like to first hear that you're open to incorporating improvements along the lines you asked if I'd like to see. In other words, I'd like to hear that you see a need for improvement. For example, I think that the policy should have one definition for "personal information", but the current draft has three (and there's a fourth here!
I think it should be the policy itself "that describes what sorts of browser sniffing may happen", not a non-binding FAQ. At the moment, neither does. And LVilla thinks browser fingerprinting relies on cookies; it does not, so a discussion of what cookies are kept for how long can't cover sorts of browser fingerprinting may happen. --Elvey (talk) 21:10, 23 May 2014 (UTC)
That makes sense, thank you. LuisV is overseeing this, so I believe he's the one who you should check is open to incorporating these improvements. (The Board reviews and approves major overhauls, and we've already approved this one; we don't approve or review incremental changes such as the one you're proposing, since we have ridiculously talented legal staff to handle that. And I know everyone involved wants the result to be as awesome as possible, so exactly this sort of incremental change may be made over time.) SJ talk  13:47, 24 May 2014 (UTC)
Sj, FYI: LuisV stalled and ultimately failed to respond at all.--Elvey (talk) 07:47, 9 July 2014 (UTC)
User:LVilla (WMF) User:LuisV (WMF) Hello?--Elvey (talk) 19:31, 11 July 2014 (UTC)
User:LVilla (WMF) User:LuisV (WMF) Hello?--Elvey (talk) 19:31, 11 July 2014 (UTC)

For-profit Project[edit]

I just sent an email to the Board with a request to present a business plan related with a for-profit project that will have Wikipedia Foundation with an equity.

Thanks in advance for your attention. Best regards, Francisco


Sorry to FUP, but I really believe it is important. Could be an outstanding idea for Wikipedia. Just need 5 minutes attention.

Thanks, Francisco


United States non-acceptance of the rule of the shorter term[edit]

FYI, [1], in particular the last bullet of the 08:53, 29 June 2014 (UTC) message. --Nemo 08:00, 9 July 2014 (UTC)

Suggestion for the Board: Technology Committee[edit]

Given recent events on the English, German, and Commons wikis surrounding MediaViewer and the troubled history of WMF product launches, I request that the Board take a more active role in engineering and product development. To do this, I propose that the board establish a Technology Committee. This request is consistent with my understanding that the Board feels that it needs to acquire more technology expertise to provide adequate oversight and guidance for WMF technology initiatives, so I hope that multiple needs can be addressed by this Committee.

  • Tasks and scope:
  • Oversee the design, project management, and testing of software products.
  • Conduct regular reviews of products that are under development
  • Ensure that useful and unbiased statistics from readers and editors are taken into consideration in product design.
  • Consult Wikimedians at important milestones in product development and ensure that their views are carefully considered by WMF.
  • Give final approval to the launch plans for major product changes and new products.
  • Oversee the curation of ideas for new products.
  • Oversee the prioritization of human and financial resources for the software product portfolio.
  • Ensure that deliverables are produced in a timely and cost-effective manner.
  • Other activities
  • Review major contracts for technology-related services, and make recommendations to the Board about major technology contracts.
  • Oversee the distribution, commissioning, major maintenance, and decommissioning of data centers and other high-value hardware.
  • Oversee the creation and implementation of data privacy and security measures.
  • Oversee risk management for technology matters.
  • Oversee the recruiting, selection, evaluation, and compensation of high-importance technology staff
  • Composition:
  • Two Board members. Their committee membership will be renewable once consecutively for a maximum of four consecutive years.
  • One member from a non-Wikimedia Foundation organization that uses MediaWiki or other software created, maintained, or used by the Wikimedia Foundation. This member will be appointed by the Board for a two-year term. Terms will be renewable once consecutively for a maximum of four consecutive years.
  • One member selected by the Funds Dissemination Committee from within its membership for a term of up to two years or until the member's FDC membership ends. Terms will be renewable twice consecutively for a maximum of six consecutive years.
  • Four members from Wikimedia content communities appointed in a community-wide election in a manner similar to Steward elections. These members will be appointed by the Board for two-year terms, with two members appointed or re-appointed each year. Terms will be renewable twice consecutively for a maximum of six consecutive years. For the first round of elections, the two candidates with the most positive votes will receive 2 year terms and the remaining successful candidates will receive 1 year terms.
  • Three members, appointed by the other members of the Committee, who have expertise in one or more of the following areas. These members should be drawn from within the Wikimedia contributor community or be from mission-aligned organizations. The Committee is strongly encouraged to appoint members who have expertise in more than one of these domains and to have at least one expert in each domain on the Committee. These members will be appointed for two-year terms. Terms will be renewable twice consecutively for a maximum of six consecutive years.
  • Technology product management
  • Human resources for technology projects
  • Finance or accounting for technology projects
  • Legal issues that are relevant to projects currently being supervised by the Committee
  • Software user experience or design relevant to projects currently being supervised by the Committee
  • Research or analytics relevant to projects currently being supervised by the Committee

This is a draft proposal and I encourage the Board to use it as a starting point for discussions. I also urge the board to look at the recent discussions about MediaViewer on English Wikiepdia 1 2 3 4, German Wikipedia 5 6, Wikimedia Commons 7, and Wikimedia-l 8 and think about how the Board can prevent this kind of situation from occurring repeatedly.

Thank you, --Pine 08:00, 12 July 2014 (UTC)

  • Support Seconded It sounds like hard work for Tech Committee members, but it would probably act as a great governor in the process and would be likely to push for early types of user testing and user case validation that may provide for a more mellow roll-out of changes. -- (talk) 08:16, 12 July 2014 (UTC)
  • Support: this might be a suitable form of governance for this proposal, already before the Board, and which includes the suggestions that
1. WMF planning address the issue of development of certain complex rendering markup and editing components;
2. WMF liaise actively and effectively with existing editor and reader communities in (1);
3. WMF draw up roadmap for development of complex rendering and editing;
4. WMF liaise actively and effectively with volunteer developer communities to determine required frameworks and work packages;
5. WMF allocate funds and resources to support work packages.

If those proposals were accepted, then here would be an example of an area in which a Technology Committee would be of value in helping the Board support the WMF in its strategic planning, act as a voice for the volunteer community, and constructively challenge and hold to account the coherence of the planning and the progress made in delivery against those plans. Deltahedron (talk) 12:25, 12 July 2014 (UTC)

On a related note:

  • This has not been taken with the relevant product team.
  • I believe that we should not escalate things before a relevant Team looks into them.

--Gryllida 09:45, 13 July 2014 (UTC)

  • ∞ support :/ John Vandenberg (talk) 10:33, 13 July 2014 (UTC)
  • Yes: it does look good to involve the board more closely in tech challenges. Tony (talk) 13:12, 14 July 2014 (UTC)
  • Support the basic concept. Clearly some kind of oversight is needed. —Neotarf (talk) 01:01, 23 July 2014 (UTC)
  • Comment Comment Something is clearly needed, but I am skeptical that adding a layer of bureaucracy is the best remedy. But the approach to software development in recent years has done great damage to the collegiality of our movement, and something needs to change. -Pete F (talk) 01:49, 23 July 2014 (UTC)
    If you look at this thread, it appears that a layer of bureaucracy, in the form of volunteer advisors, was actually *removed* with this mass desysopping of volunteers. And Sue's subsequent statement "occasionally volunteers have overridden decisions made by staff ... occasionally, those discussions have been extremely time-consuming..." points to some kind of issues with ad hoc volunteer oversight. —Neotarf (talk) 16:17, 23 July 2014 (UTC)
I don't see that specific discussion as being directly relevant, but your comment suggests something to me. It seems to me there are three general philosophies that WMF could theoretically take, to help build and maintain its own understanding of what happens in its various volunteer communities:
  1. Listen to whoever comes to them with problems, ideas, insights, etc.
  2. Create a formal structure, and communication channel, for communities to present problems, ideas, insights, etc.
  3. Build an internal capacity to better observe, listen, and surface problems, ideas, insights, etc.
 #1 is what we've had from the beginning, and I don't think anybody needs to be persuaded that we have long since outgrown the stage where #1 can be effective. #2 seems to be what is proposed here (and has been implemented in various other places in the wikiverse).
I believe that #3 is the way to go. In order to do #3, the organization would have to prioritize this issue in its organizational development and hiring, and to date, it has not done so.
It's impossible for us in the community to compel the organization to do #3. Pushing for #2 is more possible; #2 is a clearly defined intervention, something that could be promoted, campaigned for, established as a popular way forward, and implemented. But I do not believe #2 would be nearly as effective as #3.
This proposal looks to me like the community trying to micromanage the organization. This makes me wonder: in general, when does micromanagement occur? I'm sure this is a phenomenon that has been studied. I'd guess it's something that happens in the absence of clear shared expectations and good lines of communication. If that's the case -- or anything like it -- I'd rather see the underlying issues addressed, than the mere treatment of symptoms. -Pete F (talk) 16:50, 23 July 2014 (UTC)
See w:en:Micromanagement#Causes. The article blames most of micromanagement on the manager's personal psychological problems. The external causes listed (e.g., increased time pressure) are mostly irrelevant to Wikipedia. AFAICT in a brief search, the article is consistent with the literature.
My primary concern with this committee-based approach (which has been suggested by staff before) is that it would not achieve the desired goal. Imagine that the committee approves something that breaks your workflow, or the workflow of any dedicated contributor. Can you imagine our most active, independent contributors saying, "Oh, well, it screws up everything for me, but 'The Committee Approved It', so I guess it's fine after all." My guess is that most editors who are badly affected by a change (even if it actually is an improvement for most people) and currently blame "the WMF" or "the devs" would simply add the new committee to the list of incompetent people who are bent on destroying the projects. WhatamIdoing (talk) 17:31, 23 July 2014 (UTC)
Thanks @WhatamIdoing:, I agree very much with the way you've put it. -Pete F (talk) 20:06, 23 July 2014 (UTC)
According to the Wikimedia Foundation Board Handbook, the Board should Support and advise the Executive Director and senior staff without micromanaging. Assuming that it does this at present, why should it fail to do so with a Technology Committee? Deltahedron (talk) 20:57, 23 July 2014 (UTC)
Sure, there is a big, big, difference between micromanaging and ensuring that Trustees have enacted their duty to hold senior management to account by retaining sufficient oversight of operations. This is written into UK charity law so that trustees are themselves legally liable if charitable funds are misused, or the charity or its employees break the law. I presume US law has similar obligations on trustees. Oversight itself, is often delegated to committees where this has to involve a lot of special reports, such as the annual reports, and many charitable organizations have project or technology oversight committees as part of their governance system (i.e. providing assurance directly to the board of trustees without requiring approval of the Chief Executive). -- (talk) 12:54, 24 July 2014 (UTC)
I believe Pete said that his concern was about core community members trying to micromanage the organization, not that the Board was or would. WhatamIdoing (talk) 19:12, 24 July 2014 (UTC)

Not very urgent questions about Teams commitment, related to the above[edit]

On an unrelated note I would ideally like this things to be done:

  • To dedicate a separate new team to the documentation process, including localisation of the MediaWiki documentation, as well as any extensions WMF develops;
  • To prevent the WMF engineering from abandoning any extensions it develops, like this one. Maintaining a project is one of the most important phrases of its life-cycle;
  • To prevent any WMF team from making decisions based on purely one-project trials, such as this decision based on results of pilots on 2 Wikipedias but not any other sister projects.

--Gryllida 09:45, 13 July 2014 (UTC)

Request: clarify policy for on-wiki Office actions[edit]

I request that the Board pass a resolution similar to the following.

"The Wikimedia Foundation will almost always execute the decisions made by local communities with regards to whether a particular software feature is activated on their projects. Requests to opt-out of default activation or deactivation of a feature must be renewed every 6 months, otherwise the WMF will set the feature to its default state. WMF fundamentally respects the communities' rights of autonomy and will not impose an office action on the technical operations or features of a wiki unless necessary to maintain the security, privacy, technical stability, or legal status of the site." --Pine 07:45, 13 July 2014 (UTC)

The term 'Office' action in your section title is very inappropriate here. afaics, Erik's action on English Wikipedia is not an 'Office' action. Anyway...
While I would prefer that WMF did pass a resolution something like this, I do support for the 'software developers' and sysadmins being a separate community with their own processes that other communities need to accept, which is where Limits to configuration changes. The problem is with the WMF user acceptance & deploy processes; not the relationship between devs/sysadmins and content communities. For example, I would prefer that the WMF commits to keep one of its own feature in beta until there has been an RFC accepting the feature, and from a software engineering perspective the feature should stay in the 'Beta features' list even after it is flicked to opt-out, so that it doesnt suddenly change to be buried in some user preference panel, and so that the opt-out status can be changed back to opt-in easily in the first few months. Ideally the opt-in/out status is a toggle that the local 'crats or sysops can change. John Vandenberg (talk) 09:52, 13 July 2014 (UTC)
The on/off switch is only a last resort, though one that it's good to have. The problem here, as usual, and as usual without any magic solution available, is our complete inability – in most cases – to have a proper agile software development where the users are involved in building the software since earliest phases. The more something is unwanted and disliked, or fundamentally broken, the more actual users will walk way disgusted from its discussion (hence discussion is dominated by a self-selected and biased pool of persons interested in the project a priori)... until, maybe one or two years later, the result explodes on everyone's face.
The answer the board should have is whether their organisation is able to stop or correct wrong initiatives before throwing millions of dollars at them. (Especially because the millions are spent in staff time, which proportionally adds to interaction and time needed from an already-exhausted community. So each million spent in staff time probably costs multiple millions-worth of volunteer time subtracted from editing work; the gains for such costs must be very clear beforehand.) --Nemo 09:07, 14 July 2014 (UTC)

Grantmaking committee authority[edit]

Note: this is not a time-sensitive request, unlike my other two requests above, but it fits with the theme of WMF trusting its users to make decisions.

Currently, the FDC, GAC, and IEG are considered merely advisory. I feel that the community can be trusted with expanded authority when a grants committee develops consensus. I would ask the Board to approve a policy something like this:

"When a Wikimedia Foundation grantmaking committee of volunteers reaches a consensus against a proposal with at least 4 eligible volunteers having voted and at least 60% of the votes opposed to the proposal, WMF will not override the committee unless a successful appeal is made to the Board. WMF may override a committee consensus recommendation to proceed with a proposal although that override may be appealed by the committee to the Senior Director of Grantmaking, to the Executive Director, or to the Board."

--Pine 08:02, 13 July 2014 (UTC)

Oppose until and unless there's a secure voting scheme. By which I mean a ballot box that can't be stuffed. --Elvey (talk) 23:11, 18 July 2014 (UTC)
Oppose As a grantee, and also as an observer or participant in deliberations about many grants under the GAC's purview, i am generally very impressed with how well things work. Disagreement is a given when decisions around money are made, and should not be interpreted in itself as a reason for structural reform. I have zero experience with the other programs, but I do have faith they are being run in a similarly responsible manner. I see no reason compelling this decision; and even if there are problems, I would prefer to see them explored separately from a proposal for a specific remedy. Even if there are problems that must be solved, there might be other ways to solve them. -Pete F (talk) 01:46, 23 July 2014 (UTC)