As the GSoC project period has come to a close, I want to give the Wikimedia community an update on the status of my project to improve MediaWiki’s watchlist feature.
Thus far, the project has added watchlist grouping, permissions to make watchlists publicly viewable by other users, and a new raw watchlist page. Although these features are still at an experimental phase, I would like to solicit ideas from the greater Wikimedia community for a more detailed plan in preparation for a Wikimedia deployment.
The primary component of the project yet to be realized is revamping the user interface. I’ve done some tinkering with jQuery and Ajax as implemented in MediaWiki, however I opted to focus on server-side operations initially, so that client-side additions would not need major changes later on.
I’m currently looking for other developers who would be interested in collaborating on this project, especially UI designers. If there is a specific feature or improvement you would like to see, please let me know – you can adopt it or suggest someone who would be interested in working on it with me.
Finally, there are several people I’d like to acknowledge: My mentor, Alex, for always being there when I needed him; Reedy, Eranroz, and Nikerabbit for being excellent, eagle-eyed debuggers; and Sumana and Greg for being awesome GSoC project coordinators!
I truly enjoyed this unique opportunity to work with Wikimedia over the summer. Working through GSoC has given me my first real form of paid work experience in programming. It has shown me that the greatest challenge of distance work is organizing people in the community who may be juggling numerous other responsibilities. My advice for future GSoC students: manage your time wisely, communicate early and often, and strike a balance between independent and collaborative problem solving. I look forward to working with Wikimedia and other open source projects in the future.
2:09 am • 28 August 2012 • View comments
New updates: code cleanup, raw watchlist editing
I’m happy to report that the Watchlist Grouping project has reached a new milestone. As of today, all of the “required” tasks (outlined in the original project proposal) have been completed. However, this project is far from being a finished product, and I look forward to continuing my work with MediaWiki long after the GSoC work period.
Link to the most recent changeset: https://gerrit.wikimedia.org/r/#/c/16419
Here’s an update on my work:
- Last week I received a ton of useful feedback from Reedy and iAex for making my code more efficient and organized. I have implemented most of the suggested changes in my latest update. Of particular interest is a suggestion by Hashar to convert WatchlistGroup class into an object initialized with a User object. Such an approach could be modeled by the WatchedItem class already in place.
- I have added indices for the watchlist and watchlist_groups tables in the database and better support for PostgreSQL. Since database work is not my strong point, I’d appreciate extra feedback in this area.
- The raw watchlist editor now support groups. Initially, I wanted to use wiki markup to denote groups in the raw watchlist. However, I’ve found that using separate textareas for groups accomplishes the same objective without requiring superfluous parsing. The primary downside is the additional screen space needed to display the lists. This could be mitigated by making the textareas collapsible.
- Continue cleaning up added code and responding to feedback.
- Reduce database calls. One example is to eliminate calls to getGroupFromUserTitle from a loop that runs every time the watchlist is loaded.
- Continue adding documentation/comments in code.
- Add the mw-collapsible class to the raw watchlist editor (or find a different way to collapse form elements).
- Plan better UI for watchlist group editing page.
- Migrate WatchlistGroups static methods to object-oriented structure.
4:22 pm • 31 July 2012 • View comments
Watchlist Grouping Changeset (first alpha)
I have uploaded the first alpha changeset for the Mediawiki Watchlist Grouping project: https://gerrit.wikimedia.org/r/#/c/11587/
Here are some random notes on this first release:
- Database support is lacking at the moment. I’ve created setup scripts for MySQL and Postgre, but I am still working on the upgrade scripts.
- Watchlist pages now take user and group inputs as subpages. For example, Special:Watchlist/Admin/Cities will retrieve the user Admin’s watchlist group entitled “Cities”. Special:EditWatchlist works in the same way, except it will only take the group as a subpage (since users cannot edit watchlists belonging to other users.) Alternatively, these settings can be passed as url parameters (?user=<someuser>&group=<somegroup>)
- Filtering options will need to be modified to take user and group settings.
- After addressing these points (and any others that come up during testing), I’ll be working on implementing inline group adding from article and category pages and group permissions as well as modifying the raw watchlist to work with groups.
July timeline for the project (tasks begin on the specified date):
- June 25: Correct errors identified by jenkins (database table creation) and clean up code for style/efficiency. Collect feedback from other developers on how to proceed.
- July 2: Continue implementing permissions.
- July 9: Modify the raw watchlist.
- July 23: Inline group adding from article and category pages.
- End of July: Assess progress and plan next steps.
Now that the UI is usable, my goal is to release a changeset after each of these tasks is completed.
If you have any questions regarding this project, please comment on the changeset in Gerrit or this post. I appreciate any feedback from the development community.
1:59 pm • 22 June 2012 • View comments
A couple weeks ago, I found a pretty neat idea I’ve been trying to incorporate into my improvements to the MediaWiki watchlist. Arun Ganesh made this mockup screenshot demonstrating potential enhancements to the watchlist, most notably a visual edit summary bar that breaks down gross changes to an article’s character count as a percentage of the whole article, replacing the net change number.
So what would it take to implement this idea? Well, to start, a Diff object is necessary to determine how the article changes, taking a count of added, removed, and unchanged characters by paragraph. This count could occur right after a revision is made, and the data could be stored in three variables (rev_len_added, rev_len_deleted, and rev_len_unch) in the revision table of the database. I don’t believe this approach would significantly decrease performance. This aid (similar to the like/dislike bar on Youtube) is more intuitive for new editors who track article evolution over time, or simply more informative for combating vandalism.
Have any suggestions for this component of my project? Please leave a comment on this post. For the next few days, I’ll be testing various approaches to grouping in watchlists, but I will return to this idea soon.
1:43 am • 27 May 2012 • View comments