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.

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)
Yes, that's right. I want to point out, however -- the section of the Wikipedia article you quote opens listing "doubts about competence" -- which is, I think, the closest thing to my concern, and not necessarily related to anybody's psychological problems. Though "competence" is a harsher word than I would choose, I believe this is the dynamic that's currently at play: the WMF has done a number of things in software deployment that have been poorly received. I believe the best solution is for the WMF to focus on improving its ability to predict how things will play out, and work effectively toward desirable and non-dramatic outcomes (approach #3), not for the community to try to micromanage the WMF's approach (#2). But again, #3 will probably take a major effort on WMF's part. If it doesn't happen, I don't know exactly what the result will be -- but I don't think any of us will like it. -Pete F (talk) 20:38, 24 July 2014 (UTC)
I believe that the phrase "micromanagement, such as detail-orientedness, emotional insecurity, and doubts regarding employees' competence," is meant to be a description of micromanagement. That is, doubting the competence of all your employees is symptomatic of micromanagement, not causative. Similarly, being detail-oriented doesn't cause micromanagement. The ==Symptoms== section emphasizes an inappropriate attention to details as a symptom. WhatamIdoing (talk) 16:59, 25 July 2014 (UTC)
In what way is the proposal to create a Board Technology Committee micromanagement by the community? Is the proposal in itself micromanagement, and if so, of whom? The Board? Or is it the list of proposed members micromanaging the Board? Or is the fear that those core members would use the Committee as a vehicle to micromanage the staff? Oh, and just who are those core members with such a power? Deltahedron (talk) 17:15, 25 July 2014 (UTC)
What Pete originally said was, "This proposal looks to me like the community trying to micromanage the organization." I used "core community members" as a more precise phrase, because (as Pete knows) "the community" doesn't exist: it's "the communities", and there are dozens, if not hundreds, of them, and they sometimes have contradictory goals.
Pete and I both definitely qualify as core community members; we've both made tens of thousands of edits and are regularly active in metapedian and other work that happens with the communities rather than directly in the mainspace. I don't know if you would consider yourself as belonging to that category; at some level, it is a matter of self-identification. In theory, it doesn't matter who the core members are. In practice, only core community members from major projects have any realistic chance of being elected to something like this. WhatamIdoing (talk) 20:43, 28 July 2014 (UTC)
Well, that certainly puts me in my place. Now let me repeat the more important question: In what way would this proposal constitute people like you and PF trying to micromanage the organisation? Deltahedron (talk) 21:45, 28 July 2014 (UTC)
At this point in the discussion, I don't think my concept of "micromanagement" is really so helpful. It seems to me, @Deltahedron:, that we came to some understanding below, and I think that's the more important thing. I'd suggest we just drop the "micromanagement" concept as my failed attempt to communicate something, that I think has now been adequately communicated in other ways.... -Pete F (talk) 23:27, 28 July 2014 (UTC)
Fair enough. Deltahedron (talk) 06:15, 29 July 2014 (UTC)
I do not see 2 (Create a formal structure, and communication channel, for communities to present problems, ideas, insights, etc.) and 3 (Build an internal capacity to better observe, listen, and surface problems, ideas, insights, etc.) as antithetical so much as complementary -- I would say that both are now vitally necessary. It seems to me that formal structures are now inevitable, the current informal arrangements being no longer fit for purpose. It has been pointed out that there are 75,000 active editors on 800+ WMF wikis and thousands of communities in 200+ languages. With the best will in the world, existing staff arrangements, or any plausible increase in their capacity to better observe, listen etc, are not going to be enough. Formal structures are going to be necessary to prevent the staff either sinking under the weight of volunteer expectations or withdrawing into some kind of siege mentality. Deltahedron (talk) 21:23, 24 July 2014 (UTC)
By the way, it would be interesting to hear from supporters of 3 (Build an internal capacity to better observe, listen, and surface problems, ideas, insights, etc.), especially those who believe that 2 is not wanted or needed, as to how they might propose to build this capacity? Deltahedron (talk) 21:38, 24 July 2014 (UTC)

I agree that formal structures are needed; I think the key differences between #2 and #3 are in whether those structures are internal to the WMF or external, and whether they are composed of paid staff or volunteers.

I think there are a lot of ways #3 could be implemented. I may not have enough expertise, and have certainly not devoted the necessary time, to make a strong or specific proposal. That's probably work that's better suited to the Board or the ED anyway. But for the sake of clarifying what I have in mind, I think something like this would be worthwhile:

  • Create a new C-level position (silly "draft" title for the sake of discussion: Chief Collegiality Officer). CCO has primary responsibility for the relationships between the WMF and its various constituencies (readers, regular editors, occasional editors, professors, software developers, etc.) CCO is also responsible for carrying institutional understanding of healthy and unhealthy dynamics within those communities, and developing a practical understanding of what can be done to improve their health.
  • CCO's qualifications have nothing to do with technology; a good candidate might have a background in social justice movements, government, governance of a large university or parks system or similar, organizational development.
  • Reorganize within WMF so that some relevant existing positions report to CCO.
  • CCO has (shared) authority over any action of WMF that can impact relationships with those constituencies: new software features, amendments to TOU and other policies, grant programs, etc.

Like I said -- the bullets above are just a sketch, not a proposal. That's the kind of thing I mean. It's possible the same sort of thing could be achieved without a new hire, but by restructuring the existing organization, redefining responsibilities, etc. I wouldn't rule that possibility out, it may well be the better approach; but it's harder for me to sketch out an idea under that model. -Pete F (talk) 19:36, 25 July 2014 (UTC)

Then we are pretty much in agreement, in that a Chief Officer with a formal remit is to my mind an example of (2), namely a formal structure and a communication channel. To me (3) is about culture, attitude and mindset of WMF staff. I happen to believe that in certain places that needs changing, perhaps a lot, but I don't see how that would happen without being driven from the very top. Deltahedron (talk) 19:44, 25 July 2014 (UTC)
Glad to hear it. I hope this clarifies my position -- I'm not contesting the need for some kind of major change -- far from it; I'm just not confident that the specific proposal put forward here is an effective way to bring it about. -Pete F (talk) 19:49, 25 July 2014 (UTC)
And @Deltahedron: I can see now, the way I defined #2 and #3 was not so great -- I can see how it lead to the misunderstanding. You're right, the stuff I have in mind for #3 absolutely constitutes "formal structures" so I should have defined those better. -Pete F (talk) 19:51, 25 July 2014 (UTC)
It is worth noting that the WMF wmf:staff and contractors include a
Chief Communications Officer, whose "team leads the Foundation's efforts to openly and effectively share information—about the Wikimedia movement, the Wikimedia projects and the Wikimedia Foundation's work itself—with a global audience including volunteer editors, site readers and other stakeholders."
Legal and Community Advocacy team, "charged with carrying forward the Foundation’s goals of advocating for the community"
Community liaison who "help to communicate and facilitate new software (changes)"
There's a lot of aspiration here for collegiality. I wonder whether it's all being harnessed effectively. Deltahedron (talk) 20:12, 25 July 2014 (UTC)
Yes, I agree -- there are a number of positions that have responsibility for pieces of this. I believe organizing them in a way that more clearly establishes responsibilities and accountability, in the interest of improved health throughout the movement, is key to the WMF's continued success. -Pete F (talk) 20:42, 25 July 2014 (UTC)
  • On the putative Chief Collegiality Officer. I would be concerned if the CCO were indeed quite unqualified in technical issues. I would suggest that that the Chief Officers of a high-tech organisation like WMF need to be technically competent at least, in addition to any other qualifications. Otherwise the technical savvy has to come from somewhere -- such as, for example, a Technology Committee ... Deltahedron (talk) 17:58, 26 July 2014 (UTC)
    • "unqualified in tech issues" is not exactly the way I'd put it. The thing is, the Wikimedia vision doesn't fundamentally have anything to do with technology; technology just happens to be one of the best kind of interventions we have to pursue that vision. Running a complex organization with a lot of stakeholders -- say, governing the USA -- involves a lot of technology; but do we expect a presidential candidate to be a programmer? Or do we expect them to have a good enough grasp of technology and management to delgate technical aspects of the position effectively, and work well with the team they hire? I think it's the latter, and I don't see why it should be different for Wikimedia. (I wrote an op-ed piece that talks about this on a general level a few months ago.) Does that make more sense than how I put it before? -Pete F (talk) 00:52, 28 July 2014 (UTC)
An interesting point. But since WMF is, at least at present, engaged in high-tech work as part of its core business, and I am quite clear that all the leader of such an organisation need to understand what it is the organisation is doing. I believe that it is not possible to manage, or lead, abstractly. Deltahedron (talk) 06:18, 29 July 2014 (UTC)

I'm following this discussion with a lot of interest. Several things said are worth to consider and I agree that the current situation is nothing to be proud of nor to be continued without adjustments. However, a german phrase crossed my mind "Und wenn du nicht mehr weiter weißt, dann bilde einen Arbeitskreis". (Something like "And if you don't know how to carry on, create a working group.") . Given that The WMF focuses on product and engineering and wants to accelerate technical improvements (and needs to), how should that kind of committee be structured or supported to avoid being an obstacle in the process? Do you consider to let readers also have a say, or is this the part you assume the WMF to cover with sufficient competence? Creating a committee looks like an easy approach at first sight, but when we think this further, we need to ensure not to create more administrational overload at the same time. Alice Wiegand (talk) 19:32, 29 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)