Wikipedia talk:Requests for comment/Education Program extension

If you would like any user rights on the test installation, just ask. --Sage Ross (WMF) (talk) 12:52, 15 August 2012 (UTC)[reply]

I would like user rights to test the extension

Be sure that you've visited the test2 wiki while logged in before requesting rights, so that your account will be auto-created there.

your name here

Known bugs

See the list of open bugs and enhancement requests. The significant bugs will be fixed before deployment. The most noticeable:

The "MyCourses" special page doesn't show the recent activity it is supposed to, probably because of a conflict with another extension. [1]

Find a new bug?

Note any other bugs you find here (or submit bug reports for the extension on Bugzilla).

Terrible design

IMO the design of this extension is terrible. It is a webapp being deployed into the wiki.

It should use wiki pages for textual content (e.g. Commons has 'Institution' pages like commons:Institution:New York Public Library), categorisation of users (Category:Wikipedians), and provide new special pages that are transcludable tools. e.g. I should be able to use the new dynamic user-article-reviewer table should work on Category:Wikipedians by WEP institution: New York University, Category:Wikipedians by alma mater: New York University, Category:Wikipedians in New York , Category:Candidates for speedy deletion as copyright violations, Category:Candidates for speedy deletion as attack pages, Category:Good article nominees, or Category:Pending DYK nominations. John Vandenberg ^(chat) 00:34, 24 August 2012 (UTC)[reply]

This is useful feedback. I'd also like to see future development of the extension include ways of accessing and using the user-article-reviewer data elsewhere such as through categories. I'd also like to see more wikitext-level control of how all course and institution pages, or individual pages, get displayed. I'm not sure what the best way to achieve that is, but maybe something like MediaWiki: namespace pages that determine the layout, so that the community can design and redesign the course pages without forcing the people using the course pages to dealing with (and potentially break) the layout markup themselves.--Sage Ross (WMF) (talk) 14:36, 24 August 2012 (UTC)[reply]

Document the use cases, write user requirements, build, test and deploy. If you must deploy an half-baked solution in the interim, please put it in the "Special" namespace. As far as I can see that wont limit the webapp at all, except the URLs wont be as pretty. If you don't, expect all sorts of things to break, and a different segment of the community will be annoyed. Pages in all other namespaces are expected to be readable and editable using the API, e.g. gadgets and the bots, using wikitext. Is there a design doc for how this namespace will work in the API?

This current webapp design replaces wikitext with a very limited UI, thereby taking the design, automation and general ingenuity capabilities away from the community and restricting it to the developers, who will lack time to keep up. The WEP should use the existing infrastructure. ;-) Why should WEP get special tools when other review workflows are managed by the community using bots etc.? Of course doing it by bots would need to be resourced, and a non-bitey bot will need to have exception handling reports that users (..possibly staff..) need to monitor and action in order to keep everything working smoothly. But that is part of life doing projects on a wiki. John Vandenberg ^(chat) 08:03, 31 August 2012 (UTC)[reply]

This extension is a tangible step forward for keeping track of what courses are doing. The flexibility and complexity of full wikitext project pages is a double-edged sword; for newcomers, it's often overwhelming, and the first casualty is complete lists of students' usernames for each class. Having that student/class information built into the software in an inflexible way is basically the core purpose for this initial version, so that we, as experienced editors, can then monitor groups of students in a reliable way. Note that the "course description" section actually is wikitext, with a history (which, I believe, is why it doesn't simply use special pages). So it would be possible to have a fair bit of flexibility even with this initial version, if we transclude templates into the course description pages.

I'm not sure how this extension works with the API; I'll ask the developer, Jeroen De Dauw, about that.--Sage Ross (WMF) (talk) 16:19, 31 August 2012 (UTC)[reply]

Or it could be built as a special page which can be transcluded into a normal wiki page.. John Vandenberg ^(chat) 16:52, 31 August 2012 (UTC)[reply]

I do like that idea. I'm not sure if it's a possibility for future iterations or not, but I'll bring it up with Jeroen.--Sage Ross (WMF) (talk) 16:56, 31 August 2012 (UTC)[reply]

Reading through the stuff on the content page, it seems to me that most people want more integration, for instance with the new page patrol feeds. I got similar feedback after implementing the campaigns functionality for UploadWizard, which is something conceptually similar to what we're doing here, but was implemented as a special page. With as consequences that it was not well integrated because

It has a different interface and workflow then regular articles
It has no version history
Deletion cannot be reverted, neither can any type of vandalism
It has no associated discussion pages
Edits do not show in recent changes or the page log stuff
... the list goes on really

We now have all of that - I don't think like the idea of giving all that functionality up, as it really increases usability and robustness a lot. --Jeroen De Dauw (talk) 18:41, 1 September 2012 (UTC)[reply]

The problem isnt that more features are needed, or even that it is a special page. The extension is starting a new namespace rather than staying in the Special: namespace, and that would take half a day to fix. John Vandenberg ^(chat) 21:01, 25 September 2012 (UTC)[reply]