Grants talk:IEG/MediawikiFS

Feedback on first draft

Thanks for submitting this draft! Just a reminder that the deadline for round 2 proposals is Sept 30th. Please don't forget to add the amount you're requesting for the budget, and also tell us a bit about yourself in the participants section, and when you're all ready for the proposal to be reviewed, just update the status in the infobox (status=PROPOSED), so that we know you're ready for review.

2 initial questions:

1. Can you confirm that your plan meets the eligibility requirements for Individual Engagement Grants? (particularly in terms of not having WMF dependencies for hosting, integration, etc that we look for in technical projects)
2. How do you plan to ensure that the MediaWiki community uses your tools after they're built? For technical projects, we particularly want to know that software will be put to lots of good use by the community by the end of the project, not just built, so having a sense of who in the MediaWiki community will be standing by waiting to download this would be very useful.

Best of luck completing this proposal! Cheers, Siko (WMF) (talk) 22:07, 24 September 2013 (UTC)

Hi, Siko! Thank you for reminder. About questions:

1) Sure, i can confirm that. I will provide full legal name and address. I am involved in Mediawiki community (have discussions in mailing lists and some gerrit commits merged, extensions published). This project have no WMF dependencies for hosting, integration, etc. Project could be implemented fully by myself. I have C# and Python coding skills, and as you can see there is already preview prototype coded.

2) Project gained some endorsements and attraction here and in Mediawiki mailing lists and other discussions. Also, i believe in idea of "MediawikiFS" and "Mediawiki IDE", so i will keep promote it in community after release by recording screencasts and writing topics.

Vedmaka (talk) 17:26, 27 September 2013 (UTC)

Emacs integration?

You mention "Any favorite text editor".... Would this project have Emacs integration? Arided (talk) 01:29, 28 September 2013 (UTC)

Hi, Arided! You will be able to edit wiki pages with any text-editor, in Emacs too (same as you edit text files). In scope of this project current roadmap there is no advanced integration with Emacs will be done. Possibly this feature can be added to features request after RC1 released. Vedmaka (talk) 07:35, 28 September 2013 (UTC)

Eligibility confirmed, round 2 2013

This Individual Engagement Grant proposal is under review!

We've confirmed your proposal is eligible for round 2 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 2 begins on 23 October 2013, and grants will be announced in December. See the schedule for more details.

Questions? Contact us.

Siko (WMF) (talk) 05:49, 4 October 2013 (UTC)

Problem being solved

The problem being solved is described as "some parts or settings are edited through files while others can be edited through the web interface". Could you please provide more details on this problem? Who is affected? What use-cases does it unnecessarily complicate? Gryllida 10:21, 13 October 2013 (UTC)

I will try to extend description of this problem:

— When developing new project or maintain current we often need things done: creating project structure via categories and pages, semantic visualizations and assemblies, parser functions, etc ralated to wiki-content. We do this in broswer on our wiki-site. Another part of this process is customizing mediawiki for project needs: write/install extensions, configuring them, configuring mediawiki settings such as user rights, uploads, cache, etc. This part usually done via IDE or file broser + text editor. This process is not consistent because we need switch often from IDE to site, we also unable to see whole structure together.

Who is affected:

— Primary target audience of this improvement are people who using Mediawiki to create and maintain own projects (like make usage of kind of open data, encyclopedy, knowledge databases, etc). With MediawikiFS concept this process will become easier and gain more consistence.

Use-cases examples:

— Creating project with Mediawiki workflow becomes easier: i checkout mewdiawiki from repository and install it. i go to my favorite IDE, open mediawiki folder. i mount MediawikiFS to mediawiki folder. Now i am able to set-up LocalSettings for my needs, edit other php-files and next to it i can create mediawiki pages and structure with syntax highlighting, dynamic autocompletion and other features IDE can provide.

— I want copy some pages from one wiki to another. I have both wikis mounted in MediawikiFS. I just drag&drop pages i need from one wiki drive to another.

— I want ad-hoc backup of some wiki pages. I have wiki mounted as drive. I just zip them to some directory.

— I want to use my favorite tool "sed" to make changes in mediawiki pages. I just use it.

— I want to be notified about changes in my wiki by desktop notifications (like Chrome ones).

Vedmaka (talk) 11:23, 13 October 2013 (UTC)

interesting examples. Ill admit sed is one that I like. In regards to backup, if you're going to use that as a use case, you should mention how and if you plan to handle versioning of pages. For desktop notifications, sure that would be cool - you should mention how you plan to handle changing wikis efficiently? Does it poll the RC reguraly? You don't need the final answer, but I'd expect the proposal to indicate you have at least thought about the problems. Bawolff (talk) 22:02, 22 October 2013 (UTC)

Over the MediaWiki API, or ?

Do I understand correctly that the thing has to operate over the MediaWiki API? It is a reasonable option, but a nature of the interface between proposed software and a MediaWiki installation is not expressed in the text. Incnis Mrsi (talk) 19:36, 13 October 2013 (UTC)

Yes, it works via Mediawiki API. Oh, you right, i should update text to point this detail, thank you! Vedmaka (talk) 19:55, 13 October 2013 (UTC)

The two sides of the stick

As an alternative to making all interaction through files only, there is an option to make all configuration variables available through web interface, for example Extension:Configure. Such tools typically lack the ability to download extensions into a directory and the users have to log in to the server manually to put new extensions files there. This could be a small effort to add interface for downloading a new extension from a given path.

What proc and cons do you see in each of the two approaches, making everything interface through files, and making everything interface through some special pages? Gryllida 20:03, 13 October 2013 (UTC)

Generally MedawikiFS concept is not targeting to handle extensions (and mediawiki) settings somehow, it targets process of structure generating threw pages markup, so we can not compare "file interface" and "special pages interface" in context of this project, this is different things. If i get your idea wrong, please correct me here.

Anyway, about configurations in mediawiki. I think it is a real big bleeding edge, produce very high entry threshold for new users of mediawiki engine in comparsion. I think Extension:Configure is very good and useful attempt in this situation, but i dreaming about native Mediawiki settings manager, kind of administrative panel, where you can install extensions, configure them and mediawiki. Something like unite interface for site setup. Something what we saw in Wordpress and other user-friendly engines. Mediawiki lack of such things and extremely need them in row with better UI.

Vedmaka (talk) 23:09, 13 October 2013 (UTC)

opposed

Various people have attempted doing similar things to this before, none of them having taken off.

• subversion extension (although I suppose that's because it is crappy)
• external editor support
• there's some sort of emacs mode for editing wikis (that's actually somewhat popular)

Given that previous incarnations of edit wikis as a file has not seen very wide adoption except among the extremely technical, i do not think this proposal would be a good use of funds. Furthermore I'm concerned how smw centric this proposal is-I don't think iegs are supposed to fund things targetted at smw. Last of all, in this proposal its implied that each namespace would be treated as a folder with all pages in that namespace. Thats not going to work on a wiki with over a million pages in a namespace (yes that's an implementation detail that can be fixed, but I thought I should mention). Bawolff (talk) 21:54, 22 October 2013 (UTC)

• +1 --Nemo 21:32, 28 October 2013 (UTC)

Aggregated feedback from the committee for MediawikiFS

Scoring criteria (see the rubric for background)	Score 1=weakest 5=strongest
Potential for impact
(A) The project fits with the Wikimedia movement's strategic priorities	3
(B) The project has the potential to lead to significant online impact.	2.5
(C) The impact of the project can be sustained after the grant ends.	4
(D) The project has potential to be scaled or adapted for other languages or projects.	3.5
Ability to execute
(E) The project has demonstrated interest from a community it aims to serve.	2
(F) The project can be completed as scoped within 6 months with the requested funds.	3
(G) The budget is reasonable and an efficient use of funds.	3.5
(H) The individual(s) proposing the project have the required skills and experience needed to complete it.	3
Fostering innovation and learning
(I) The project has innovative potential to add new strategies and knowledge for solving important issues in the movement.	2.5
(J) The risk involved in the project's size and approach is appropriately balanced with its potential gain in terms of impact.	2.5
(K) The proposed measures of success are useful for evaluating whether or not the project was successful.	4
(L) The project supports or grows the diversity of the Wikimedia movement.	2.5
Comments from the committee: Idea seems technically interesting and may serve to some user of (smallish) MediaWiki instances. Lacks demonstration of community interest. Would like to see proposal demonstrate a more valid use-case within existing Wikimedia architecture - unclear how many end users are actively waiting to use this tool. For large collaborative wikis like Wikimedia wikis, bots already exists to perform repetitive tasks (which is supposed to be one of the use cases), and (as mentioned in the proposal) there is no immediate solution to present version history and resolve edit conflicts. Missing strategic alignment. We appreciate the modest budget request, which appears reasonably balanced against potential for impact.

Thank you for submitting this proposal. The committee is now deliberating based on these scoring results.

Funding decisions will be announced by December 16. — ΛΧΣ²¹ 00:21, 14 November 2013 (UTC)

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!

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.