Grants talk:IEG/Stepwise Disclosure Edition: Wikipedia for shy people

Proposal deadline reminder

Thanks for starting this draft! I just wanted to remind you that the next IEG proposal deadline is less than 2 weeks away, so I'd encourage you to use the "finish creating proposal" button at the bottom of your proposal page to create the rest of your page and then begin filling in details about your project plan, budget, etc as soon as you're able - we're happy to give feedback or answer questions as you continue to develop this plan, so please feel free to ask for help here :) When you're all done and ready for review, just update the status in your infobox from DRAFT to PROPOSED. Best of luck, Siko (WMF) (talk) 23:48, 18 March 2014 (UTC)

About eligibility rules for technical solutions

Although we haven't reviewed your plans fully yet, I want to draw your attention to the eligibility requirements for proposals, particularly the point about technical components. If you have a technical solution in mind for this project, please note that you'd want to consider whether it could be accomplished without WMF engineering to build and deploy it (if not, that would make your project ineligible for a grant, unfortunately).

I wonder if you've looked at the new drafts namespace on English Wikipedia to see if something like this might meet the need you're describing? It isn't fully private, but it is a half-step to full publication. I can imagine an IEG project that experimented with organizing community workflows to make the best use of such spaces for shy newcomers may be welcome for various languages, and using existing technology my be simpler than trying to build something new...

Cheers! Siko (WMF) (talk) 23:48, 18 March 2014 (UTC)

Thanks, Siko. Good point. Drafts are certainly a step forward. However, it looks like drafts are thought for bright-new articles while our approach taps into existing articles. Taping into existing article introduces an additional difficulty: the parallel evolution of the public edition (the article itself) and the private draft being prepared by the "shy" contributor.

thanks again! --Jipdigao (talk) 18:07, 28 March 2014 (UTC)

Sandboxes

Hi, I'd be very curious to know whether/why editors' Sandboxes, combined with @invitations to contributors, or use of the Draft space wouldn't be sufficient to address this issue. Although those aren't technically private, they are functionally 'not live' and are far less likely to be viewed by those not directly involved. Because those are existing solutions, perhaps the problem is more promotion of those tools than lack of new ones. Cheers! Ocaasi (talk) 22:20, 2 April 2014 (UTC)

Thanks for your comment, Ocaasi. Wikipedia drafts account for a semi-public visibility (i.e. though drafts are not indexed by search engines, they are still URL addressable). The main shortcoming is that editing is no longer conducted within existing articles but in a separated area. This approach works well for bright new articles but not so clear how to use it for situational editing, i.e. when users when to work on a section or different paragraphs spread across the article. --Jipdigao (talk) 09:55, 11 April 2014 (UTC)

Hosting plan?

Hi Oscar Diaz and Cristobal Arellano,

Thanks for clarifying in your proposal that this tool would be a browser extension rather than a Mediawiki extension, to help meet our eligibility requirements. The other technical dependency that I can see for your project which would impact eligibility is hosting. Can you tell us a bit more about where/how you plan to host your Chrome extension? Do you already have a server for this (used for your other browser extension projects?) As you can imagine, for $25,000 we'd like to ensure that tools, once developed, will have a life span beyond the 6 months of this grant.

Thanks, Siko (WMF) (talk) 00:12, 8 April 2014 (UTC)

Hi Siko. No clear what do you refer to. Some options:

• if you refer to the packeted extension, it will be freely available at the Chrome Web Store. This is already the case of other extension for Wikipedia (click here)
• if you refer to the CODE of the extension so that others can branch and capitalize on the development, our option will be to go for GitHub. This is a common go for social open projects like this one. --Jipdigao (talk) 10:02, 11 April 2014 (UTC)

Eligibility confirmed, round 1 2014

This Individual Engagement Grant proposal is under review!

We've confirmed your proposal is eligible for round 1 2014 review. Please feel free to ask questions here on the talk page and make changes to your proposal as discussions continue during this community comments period.

The committee's formal review for round 1 2014 begins on 21 April 2014, and grants will be announced in May. See the schedule for more details.

Questions? Contact us.

Please note that eligibility is dependent on the project having a hosting plan that does not rely on WMF, and that no changes to MediaWiki (Visual Editor, etc) are required to support this project. If your project is recommended for funding, we will work with you to gather information about your complete plans before an IEG can be approved. Siko (WMF) (talk) 00:04, 9 April 2014 (UTC)

feedback

Hello! Thank you for your idea, never thought about engagement activities from this point of view, though at some time before I worked on the local version of Incubator in Russian Wikipedia: we focused on separate namespace and mentors but I think that your idea is even better as it would prevent from keeping plenty of drafts in Wikipedia without understanding whether author will complete it or not. I also want to ask the following questions: rubin16 (talk) 11:27, 10 April 2014 (UTC)

1. as I see, you are from Spain - why do you want to start working with American students? Probably it will be easier to start in your local region where you have more communications and you could have more involvement than travelling to the US? For example, James I University has already engaged in some wiki programs rubin16 (talk) 11:27, 10 April 2014 (UTC)
   1. Unfortunately, Spanish universities do not look as eager as US ones to engage in Wikipedia programs. As far as we know, they are "timidly" beginning to use Wikipedia, but still far from editing, not to mention to promote student engagement by consider Wikipedia editing as part of the evaluation. That said, they are some exceptions we are contacting with: Felipe Ortega (Univ. Complutense, Madrid), Francisco Rodero (Univ. Cádiz), Antonio J. Reinoso (Univ. Rey Juan Carlos, Madrid), or Carlos Solis (Univ. Politécnica Valencia). Notice these colleagues somehow work on Wikipedia but this does not necessarily means that they use Wikipedia in their classes.--Jipdigao (talk) 10:35, 11 April 2014 (UTC)
2. I suppose that you need to perform deeper analysis of target audience: from my point of view undergraduates are in their majority quite active, familiar with gadgets and Internet and I wouldn't call them "shy" :) maybe you should select particular segment as a testing audience (though I can't recommend you criteria based on which we can identify shy guys and girls)? rubin16 (talk) 11:27, 10 April 2014 (UTC)
   1. As we see the problem is not as much about technological competence but about self-confidence and do not being afraid of what people may say. You are right that the word "shy" might be misleading in the sense that the discouraging factor is not so much about shyness but peer pressure: being afraid of what your folks will say. In the proposal, we include some references to the literature where this point showed up. That said, domain experts might also be put off by public editing. After all, academic publications go through a private reviewing process before being publicly released. Professionals care about their reputation and the writings they signed. It is true Wikipedia permits anonymous editings. But professionals want to get recognition for what they do: no problem in signing good articles. The problem is the lack of a process to ensure the article is good enough... before being consolidated in Wikipedia. Stepwise disclosure permits to mimic peer reviewing without leaving Wikipedia. --Jipdigao (talk) 10:35, 11 April 2014 (UTC)
3. Is it possible to see any schedule of your project execution? rubin16 (talk) 11:27, 10 April 2014 (UTC)
   1. Certainly. Thanks for pointing this out. Check updated version --Jipdigao (talk) 10:35, 11 April 2014 (UTC)
4. How will you extension cope with possible future changes to VE: what dependents will it have? rubin16 (talk) 11:27, 10 April 2014 (UTC)
   1. Dependencies include the use of transactions to update the Document Model. We plan to isolate those dependencies using the wrapper design pattern so that all dependencies with VE will be centralized in a single component. --Jipdigao (talk) 11:50, 11 April 2014 (UTC)
5. How do you plan to promote your extension and make the community (and not only existing community, put potential editors) aware of it in the future, after the end of the project? rubin16 (talk) 11:27, 10 April 2014 (UTC)
   1. Wikipedia Foundation itself has some pages addressing Wikipedia usage issues. If the extension probes to be useful then, it could become a kind of pattern for facing "peer pressure". --Jipdigao (talk) 11:50, 11 April 2014 (UTC)
6. Some questions to the budget requested:
   • could you please provide breakdown for travel expenses? What events are you going to visit, how long do you plan to stay there? rubin16 (talk) 11:27, 10 April 2014 (UTC)
   1. Events include OpenSym or Wikimania. We roughly calculated 1000 for person and event: 2 persons + 2 events = 4,000 --Jipdigao (talk) 11:50, 11 April 2014 (UTC)
   • how many hours/days would it take you to start supporting browser-located revision history? to adapt extension to the Visual Editor? rubin16 (talk) 11:27, 10 April 2014 (UTC)
   1. Our estimates are around 240 hours with an average load of 4/5 hours a day --Jipdigao (talk) 11:50, 11 April 2014 (UTC)
   • what do you mean by "Wikimedia merchandise"? rubin16 (talk) 11:27, 10 April 2014 (UTC)
   1. This includes T-Shirts, mugs, magnetics, pens, pins for the students participating in the evaluation. --Jipdigao (talk) 11:50, 11 April 2014 (UTC)
   • what will external lecturer do? Who will it be? How long will it work and where (US, Europe)? rubin16 (talk) 11:27, 10 April 2014 (UTC)
   1. External lecturers will help with the evaluation in two ways. First, providing early feedback of mockup prototypes. Second, conducting evaluation with workable prototypes. This includes describing the extension to their students, making the demographic study (age, academic results, presence on social networks to attempt to guess their assertiveness), passing the evaluation, collecting the results, and conducting the quantitative analysis at their place. Of course, we can help since we will do the same with our own students. Besides contacting with some Spanish lecturers, we made an open call to Wikipedia Education Program. We also plan to be more proactive and address some members directly at conferences. As for the timing, we plan to have a first workable prototype three months after the start of the project. --Jipdigao (talk) 11:50, 11 April 2014 (UTC)

Best regards, rubin16 (talk) 11:27, 10 April 2014 (UTC)

Forcing people and other software

Shyness? I don't understand how it matters. "Shy" editors can just move to Wikisource or other projects, they can't hide from the environment of a wiki and there is no reason to force them to edit a wiki where they don't feel comfortable. Other than that, this seems to be only a user script to easily access some very basic features like creating user subpages, moving pages, sending talkpage messages and so on. In short, a duplicate of mw:Editor campaigns; see my comments there.[1] --Nemo 07:41, 15 April 2014 (UTC)

Thanks for the input, Nero. My feeling is that the mw:Editor initiate addresses the lack of a "campaign infrastructure" as the hindrance for editing. This is certainly a help for newcomers. By contrast, we address a different concern: shyness. No matter whether editing is conducted within a campaign or as individual effort, shyness (or peer pressure) is still there. Somehow our extension will be an additional weapon within the mw:Editor infrastructure. Technically, the proposed extension mimics Wikipedia editing but versions are locally kept rather than being disclosure at the Wikipedia server. So the aim is not at creating user pages, moving pages, etc, just editing but with visibility regulated by the user himself. The challenge is that we are not thinking about editing articles from scratch but amending/extending existing articles. This implies that your private changes should be interwoven with the public editing so that editors do not perceive any difference between directly editing the public version or keeping these changes local.--Jipdigao (talk) 16:08, 16 April 2014 (UTC)

If stuff is kept locally, I consider your proposal totally un-wiki and I oppose it. It's the contrary of what we do here and inappropriate for Wikimedia funding. --Nemo 09:39, 17 April 2014 (UTC)

Notice that the point is not where stuff begins but where stuff ends. Our proposal starts locally but ends at the Wikipedia. Hope this helps.--Jipdigao (talk) 18:43, 19 April 2014 (UTC)

I wouldn't put it so strongly as Nemo, but note that wikis have traditionally been all about an atmosphere of open collaboration (giving rise to the "wiki magic"). While it's certainly well intentioned, this project seems to be a step away from that. the wub "?!" 22:39, 19 April 2014 (UTC)

You make a good point when indicating that is "all about an atmosphere of open collaboration". Creating such atmosphere does not neccessarily imply than editing should be made readily public. In certain cases, we believe open collaboration can be better served by "stepwise disclosure edition". Sharing your drafts with close folks before being unveiled to the public might end up in better results that if readily disclosured to the public. --Jipdigao (talk) 20:26, 26 April 2014 (UTC)

Scope

• You've mentioned 'Wikipedia' in your proposal application. This is a red flag: other sister projects exist, as do other languages, and ignoring them in such proposal is inconsiderate. Please talk to other communities, get their feedback, and adjust the scope as necessary. Gryllida 22:43, 19 April 2014 (UTC)
  • Our focus is in English Wikipedia because it is needed a specific setting to build and evaluate the tool. Being build over English Wikipedia does not mean that it only will work with it, but any MediaWiki engineered wiki with VisualEditor support. Although it should work with other MediaWiki wikis, testing and adapting to them is out of the scope of this project. --Cristobal.arellano (talk) 08:37, 22 April 2014 (UTC)

• I hope this to be done for a next round, not this one, as the proposal text is unclear as to what the tool would do. A proposal evolves as it gets feedback from diverse communities, both on-wiki and tech people. Gryllida 22:43, 19 April 2014 (UTC)
  • Thank you for your comments Gryllida. If there is any specific point that is not clear, tell us and we will be glad to clarify it.--Cristobal.arellano (talk) 08:37, 22 April 2014 (UTC)

Potential problems with "page owners"

A problem with Wikipedia in the classroom came up recently where a student pasted an "improved" article in one go, overwriting the previous stub. The student's work was reverted by the page's "watcher". Page creators automatically see changes to the pages they created show up on their watchlist unless they "unwatch" them. Often called a "page owner", people who monitor the changes they see on their watchlist to pages they created can become overly protective, reverting changes out-of-hand without looking at them carefully. In this case, the page's watcher was confused by the "blob edit", which included some poor wikisyntax as well as some perceived errors, and reverted the edit, which is the worst-case scenario for anyone using Wikipedia in an outreach capacity, including the classroom. The teacher blogged about the issue here. The article the student selected to edit was en:Super-spreader. I think this case shows that 'stepwise editting' is normal behavior for new editors, and 'blob-wise editing' can seem disruptive, especially if page-watchers are not informed ahead of time. This "Stepwise Disclosure Edition" seeks to keep the stepwise editing out of sight until some pre-approval process takes place, and I think that the moral of the superspreader story is that this would be undesirable. Jane023 (talk) 12:41, 8 May 2014 (UTC)

Page watchers may or may not be exerting "ownership" issues. The more important issue is the quality of the revert and how it is presented? Does it revert a while big edit with a negative edit summary/talk page summary? Or just tweak the obvious problems with a neutral or even supportive edit summary/talk page discussion? Teaching new editors it's ok to stand up to obvious negativity, which not reading too much negativity into neutral criticism is important. Some people will read "they attacked" or else "I'm incompetent" into relatively innocuous comments and react in some negative fashion or just stop editing. So psychological preparation for various contingencies helps. User:Carolmooredc 20:14, 8 May 2014 (UTC)

Aggregated feedback from the committee for Stepwise Disclosure Edition: Wikipedia for shy people

Scoring criteria (see the rubric for background)	Score 1=weak alignment 10=strong alignment
(A) Impact potential Does it fit with Wikimedia's strategic priorities? Does it have potential for online impact? Can it be sustained, scaled, or adapted elsewhere after the grant ends?	6.6
(B) Innovation and learning Does it take an Innovative approach to solving a key problem? Is the potential impact greater than the risks? Can we measure success?	6
(C) Ability to execute Can the scope be accomplished in 6 months? How realistic/efficient is the budget? Do the participants have the necessary skills/experience?	5.7
(D) Community engagement Does it have a specific target community and plan to engage it often? Does it have community support? Does it support diversity?	3.4
Comments from the committee: Innovative proposal fits within strategic priorities and could impact editor retention metrics. The participants appear to be experienced project organizers. Allowing editors to request a review of edits to Wikipedia articles before they go live would attract some new editors. It may, however, have a negative effect by increasing complexity and making more work for other editors reviewing and approving the edits. Limiting visibility using social networks is a controversial idea both in the developer community and the contributor community. The approach goes against a core ethos of transparency in collaboration, and it could balkanize efforts to collaborate. Fairly high risk and high budget proposal that would only be accessible to Chrome users. No guarantee of future updates and localizations for Chrome browser or other broswers. The proposal looks risky in terms of technology: we would like to see a clearly feasible design that is aligned with existing infrastructure and developers' experience within the Wikimedia movement. Hosting it on a web server will cause inherent data privacy issues and implementing it in a browser extension will cause unnecessary technical complexity. Unclear if proposers can build this tool in the timeframe and have it tested properly. There appears to be little community support for this. However, this may be misleading, because the target audience is people who don't currently edit. The proposers do have a plan to create their own target community among their students, but otherwise there is no plan for promotion.

Thank you for submitting this proposal. The committee is now deliberating based on these scoring results, and WMF is proceeding with it's due-diligence. You are welcome to continue making updates to your proposal pages during this period. Funding decisions will be announced by the end of May. — ΛΧΣ²¹ 00:35, 13 May 2014 (UTC)

Round 1 2014 Decision

This project has not been selected for an Individual Engagement Grant at this time.

We love that you took the chance to creatively improve the Wikimedia movement. The committee has reviewed this proposal and not recommended it for funding, but we hope you'll continue to engage in the program. Please drop by the IdeaLab to share and refine future ideas!

Comments regarding this decision:
We appreciate seeing the experimental approach you have in mind, but we’re not seeing the necessary community support for trying such a project on English Wikipedia at this time. Thank you for taking time to share your idea with IEG, regardless - we hope to see more from you in the future.

Next steps:

1. Review the feedback provided on your proposal and to ask for any clarifications you need using this talk page.
2. Visit the IdeaLab to continue developing this idea and share any new ideas you may have.
3. To reapply with this project in the future, please make updates based on the feedback provided in this round before resubmitting it for review in a new round.
4. Check the schedule for the next open call to submit proposals - we look forward to helping you apply for a grant in a future round.

Questions? Contact us.