Talk:Outreach programs/Possible projects

Previous page history was archived for backup purposes at Talk:Outreach programs/Possible projects/LQT Archive 1 on 2015-07-10.

Considering the proposal to Improve Extension:CSS for Summer_of_Code_2013#Project_ideas... Could we have a reasoning of what needs would this solve in real projects out there? The idea sounds interesting and it is good to see a mentor backing the proposal. The proposal would gain strength if it would be clearer what are the specific problems or limitation MediaWiki sites are facing that would be solved with this project. I get the idea that now they can't use full CSS to style a single page. The question is though who wants to do this and why.

I can see somehow that better per-page CSS capabilities might help building visually attractive wiki pages and follows the line of giving more power to editors as we are doing with templates and gadgets. Still, more feedback from other developers and maintaners would be welcome.

Also more information about the mentor and his involvement in the MediaWiki / Wikimedia community would be welcome. There is not much said in the user profile(s) and I lack more background.

Thank you!

This post was posted by Qgil-WMF, but signed as Qgil.

Thanks for the feedback Qgil.

My primary interest in Extension:CSS is for wiki installations with trusted users. Often these are private/internal wikis or CMS type configurations. In these cases, I have found it beneficial to give editors more control over formatting. Often times there are one-off tables or portal pages where editors want to customize the presentation.

One of my goals for WikiFYD is to provide a variety of layout/formatting examples for portal pages, tables and other complex information. The CSS for each example would be included so anyone (with the extension) can easily use them.

Does that help?

I have also updated my user page with some relevant information.

Could those "trusted users" be defined group permissions like e.g. the editors group here?

This post was posted by Qgil-WMF, but signed as Qgil.

It would be difficult, wouldn't it? How do you (cleanly) prevent non-privileged users from adding/editing CSS rules in an otherwise editable article?

Ah, yes. Just for the sake of discussion:  :) what about having an edit submission check or a bot looking at new edits to detect CSS code. Whenever a page gets new or edited CSS code then Extension:FlaggedRevs would set that page for review by a CSScops user group. You could decide whether to show the last version of the page or not, and to which users. I'm no security expert but maybe you could activate FlaggedRevs only with specific CSS code regex instead of just anything.

Anyway, I'm digressing. I just want to make sure we don't support a project for GSOC that later on someone says that brings security holes to a MediaWiki installation.

This post was posted by Qgil-WMF, but signed as Qgil.

The proposal is to implement whitelisting. Whitelisting is a more powerful security feature than a regex or moderator review.

What gives you the impression that these improvements bring "security holes to a MediaWiki installation"?

Your proposal was moved to the "Featured project ideas" weeks ago, and it is being promoted both in Summer of Code 2013 and Outreach Program for Women. All you need to do is register as mentor in the GSOC website as requested at Mentorship_programs/Possible_mentors. Sorry for the misunderstanding.

This post was posted by Qgil-WMF, but signed as Qgil.

We need to work in our application for Google Summer of Code 2013. A basic piece is the list of projects we are proposing. This page is the main reference. Make sure the projects you want to see becoming a reality are a) listed and b) well featured. Having explicit backing of the related teams / stakeholders is also key.

This post was posted by Qgil-WMF, but signed as Qgil.

I(really) don't know what the goals for GSoC in this year, but if you can... I would like to see students working with bugs related to item 6 of section The Big Picture[1]

For example (if I'm right) bug 5856 [2] or maybe the bugs 10384 [3] and/or 38271 [4]

• [1]http://www.mediawiki.org/wiki/Wikimedia_Engineering/2012-13_Goals#The_Big_Picture
• [2]https://bugzilla.wikimedia.org/show_bug.cgi?id=5856
• [3]https://bugzilla.wikimedia.org/show_bug.cgi?id=10384
• [4]https://bugzilla.wikimedia.org/show_bug.cgi?id=38271

Thank you for your feedback!

It would be great to have a Latex centric proposal + mentor. There seems to be potential for many little improvements but I don't know the problem enough to identify one potential GSOC project.

About svg-edit, I have commented at the bug report asking for proposal + mentor.

This post was posted by Qgil-WMF, but signed as Qgil.

Will I need to draft a proposal for Wikimedia if I am applying for Outreachy, or will the Phabricator task suffice? I know there is an article on how to write a good proposal, but that seems targeted towards GSOC instead so I don't know if that's a general Wikimedia requirement or a GSOC-specific requirement.

I know the Outreachy application itself has a section to detail the project we are interested in applying for, but there doesn't seem to be any need for a formal proposal for them. I'm just wondering if Wikimedia itself requires a proposal in order to consider a candidate.

As I understand it, your proposal is a Phabricator task titled something like "Rewrite MediaWiki in COBOL (Outreachy 11 proposal)." I updated Outreach programs/Life of a successful project#Submitting your proposal with a link to a good sample proposal, and also updated Outreachy/Round 11#Candidates. I hope that's clearer :-)

Thanks for the help, @SPage (WMF), that is much clearer indeed. :)

Re: steps 1 and 2 under 'steps to get your proposal up', unfortunately I had already created a Phabricator username and a Mediawiki username some time ago and posted under both, and they are (very!) different usernames. Is there any way I can get my username changed, or should it be alright if they aren't the same?

Several Wikimedia staff have different wiki and phabricator usernames (and git name, and gerrit/labs shell name, and IRC nickname...) If you want to change your phabricator username I would ask in #wikimedia-devtools^connect; to change your username on Wikimedia sites, I think you would create a new topic on some meta-wiki page. It's OK to create a new username that you really want and move on from the old one.

Hi @Misaochaaan, the instructions can be found at Outreach_programs/Life_of_a_successful_project#Submitting_your_proposal. Our processes for GSoC and Outreachy are basically the same. Good luck!

Thanks @Qgil-WMF. I can start on this even if I currently only have one out of the two required mentors, right?

Yes, of course you can. In fact, seeing a qualified and motivated candidate does help a mentor finding a co-mentor.  :)

@Qgil-WMF for the proposal I will need to discuss the specifics of the project and my deliverables with my mentors, right? But what if we haven't gotten another mentor yet - won't we need his input as well? If someone is interested in being a mentor but is still waiting for his Outreachy mentor registration to be approved by the admins, can I/we start involving him in the project already?

Someone wonders if the step of completing a microtask should be reiterated in the instructions/workflow for submitting a proposal. It's currently mentioned in Mentorship programs/Lessons learned which is linked as mandatory reading twice, but it's not included in "Add your proposal" section and is not marked as required in the template («If you have already written a feature or bugfix in a Wikimedia technology such as MediaWiki, link to it here; we will give strong preference to candidates who have done so.»).

I added it to Google_Summer_of_Code_2014#Candidates but then I forgot to reply here. Thank you || sorry.  :)

This post was posted by Qgil-WMF, but signed as Qgil.

We need to clean this page, making it ready for Outreach Program for Women - Round 7. If you have projects listed, or you simply want to help, please edit away. Every project at the Featured section must be ready to start in January 2014 with two mentors. The rest must go to Raw, or be removed.

This post was posted by Qgil-WMF, but signed as Qgil.

I suggest we scope the featured code-related ideas at about 6 weeks of coding work to ensure we dedicate enough time (out of the 3-month period) to bugfixing and code review. Past proposals often allotted either no time or about 2 weeks for merging with trunk, pre-deploy code review, and integration. That's not enough. If skilled developer thinks that a project might take about 2 weeks for a skilled developer to code, then that's a good sign, in my opinion. Students run into lots of problems, and your 2-week project is someone else's whole summer or winter.

Just a reminder. :-)

Yes, indeed. I will add this to the lessons learned, which is also the checklist for future programs.

This post was posted by Qgil-WMF, but signed as Qgil.

See "The core tasks shouldn't take more than 50% of the available time." at Mentorship programs/Lessons learned. Thank you again.

This post was posted by Qgil-WMF, but signed as Qgil.

I need a mentor to guide me on the project
Rough Proposal

I might be able to do this if one of the current projects I've volunteered to mentor doesn't happen; I'd prefer not to do all three.

This post was posted by Mattflaschen, but signed as Superm401.

According to the maintainers this is not a good idea. However, there might be a chance for a project consisting in fixing open Vector issues.

We need to find a scope. The tracking 44881 is just too broad. Would it make sense to have e.g. a selection of UI improvements in the nav bars? Fixes or features that can be agreed with the maintainers and that they will take when meeting the quality criteria. NOT features that would require wide discussions e.g. with the Wikipedia community.

If something along these lines is possible and there is at least one mentor, we can take it for GSOC 2013.

This post was posted by Qgil-WMF, but signed as Qgil.

After discussing with Trevor Pascal, we didn't find a good scope for GSOC project. The tasks that remain are quite dull, far apart from a meaningful contribution to Vector skin UI improvements.

GSOC projects aiming to improve skinning features in MediaWiki are still welcome. For instance, how to have one skin with different color patterns that could be applied via preferences.

This post was posted by Qgil-WMF, but signed as Qgil.

I promise this is the last thread I open with a list of GSOC 2013 candidates. I will keep it updated, notifying about the projects that make it to Summer_of_Code_2013#Project_ideas and the ones that get discarded.

• Improve the mediawiki-bugzilla extension to a deployable level: needs Bug Squad buy-in and at least one mentor. Discussing with Mozilla.
• Multilingual, usable and effective captchas: project scope needs clarification. Too much / too vague for a GSOC project?
• Mentorship_programs/Possible_projects#MediaWiki LocalisationUpdate for all: does it have MediaWiki core maintainers buy-in?
• Mentorship_programs/Possible_projects#Multilingual SemanticMediaWiki: does it have SMW maintainers buy-in?

Proposed:

• Improve Extension:CSS.
• Wikidata Entity Suggester.
• Prototyping inline comments.
• Add support for x3d 3D files to MediaWiki as part of New media types supported in Commons
• Tools for migration to structured page translation.
• Create plugins for jQuery.IME for Firefox and Chrome.

Discarded:

• Extension pages management: nice idea but with unknown origin/promoter, requires significant planning and buy-in from mediawiki.org.
• System documentation integrated in source code: too complex for GSOC - see bug 46526.
• Work on outstanding Parsoid bugs and/or add features: the Parsoid team has big release in July and they are very busy. Not the best time for a student to land.
• Work on RefToolbar: we want to promote work on VisualEditor instead. The first release this Summer has basic cite support, and more can be added later on.
• Phase out the Vector extension; merge the good parts into core: not considered a good GSOC task in the current status of the project. (discuss)
• Browser Test Automation: considered not a good fit for GSOC.
• Improve accessibility of MediaWiki and MediaWiki extensions: not suggested anymore.
• Gadgets: no project.
• Write useful Lua modules: no project.
• Build an interwiki notifications framework and implement it for InstantCommons: nobody answered.

This post was posted by Qgil-WMF, but signed as Qgil.

For the x3d one. Well it wouldn't be my first choice for a project to mentor, however if I was not mentoring something else and there was a student really interested in it I could probably mentor that. On a similar note make a kml validator/media handler would also possibly make a good media-handler-extension gsoc project (and maybe a little better scoped than the x3d one)

Wouldn't KML support be bug 26059? High priority, assigned to nobody, 30 comments 16 followers and stalled... Do we really want a student to jump there? If you want to test the waters in the report please do. I'd rather put my time pushing current project candidates to become actual GSOC ideas. An equivalent to "feature freeze", I guess.

This post was posted by Qgil-WMF, but signed as Qgil.

Yeah that is the bug. I would just reccomend it be considered before x3d since from a technical prespective its almost the same project, but about half the work (and also probably has more people who care about it)

X3D support for mediawiki can be simplified by using the open source x3dom.js (http://www.x3dom.org/) - after that it's mostly about whitelisting the X3D tag set.

What about having a catch-all entry at the GSOC page for unsupported file types in Commons/MediaWiki? We could explicitly point to KML, x3d (anything else highlighted?) and link to the full list at Commons.

This post was posted by Qgil-WMF, but signed as Qgil.

Discarded: Extension pages management: nice idea but with unknown origin/promoter, requires significant planning and buy-in from mediawiki.org.

This post was posted by Qgil-WMF, but signed as Qgil.

Discarded: System documentation integrated in source code: too complex for GSOC - see bug 46526.

This post was posted by Qgil-WMF, but signed as Qgil.

I'm available to mentor the E:CSS, E:UploadWizard, the XML sitemaps extension, automatic category redirects, and/or E:OEmbed*. Which one I do I'll leave up to somebody who has a better idea of which projects WMF would prefer. Depending on the time commitment involved, I may be able to mentor more than one project.

If you could mentor Category redirects then bawolff would be available for another one. This is all relative since we might end up with other combinations as soon as interesting project proposals from students show up, but it would be a good combination to start with.

This post was posted by Qgil-WMF, but signed as Qgil.

Sounds good to me.

Discarded: Work on outstanding Parsoid bugs and/or add features: the Parsoid team has big release in July and they are very busy. Not the best time for a student to land.

This post was posted by Qgil-WMF, but signed as Qgil.

Discarded: Work on RefToolbar: we want to promote work on VisualEditor instead. The first release this Summer has basic cite support, and more can be added later on.

This post was posted by Qgil-WMF, but signed as Qgil.

Proposed: Improve Extension:CSS.

This post was posted by Qgil-WMF, but signed as Qgil.

Proposed: Wikidata Entity Suggester.

This post was posted by Qgil-WMF, but signed as Qgil.

Browser Test Automation: needs at least one project idea.

I am not sure what would be a good project idea. For now we have this: "The goal would be to create decent test coverage for a feature or an extension. ... Good example would be Extension:MobileFrontend extension." Is that good enough?

This post was posted by ZFilipin (WMF), but signed as Zeljko.filipin(WMF).

As said in wikitech-l: 12 weeks of a student to get good coverage of MobileFrontend automated testing? Maybe, but... One thing is the amount of work. Another thing is that it feels like quite volatile / WIP work. I'm open to be convinced, though.

We need to solve this today. Let's chat / talk.

This post was posted by Qgil-WMF, but signed as Qgil.

Discarded: Browser Test Automation: considered not a good fit for GSOC.

This post was posted by Qgil-WMF, but signed as Qgil.

Proposed: Prototyping inline comments.

This post was posted by Qgil-WMF, but signed as Qgil.

Proposed: Add support for x3d 3D files to MediaWiki as part of New_media_types_supported_in_Commons

This post was posted by Qgil-WMF, but signed as Qgil.

Proposed:

• Tools for migration to structured page translation.
• Create plugins for jQuery.IME for Firefox and Chrome.

Discarded:

• Improve accessibility of MediaWiki and MediaWiki extensions: not suggested anymore.
• Gadgets: no project.
• Write useful Lua modules: no project.
• Build an interwiki notifications framework and implement it for InstantCommons: nobody answered.

This post was posted by Qgil-WMF, but signed as Qgil.

Suggestion, "Implement SASS or LESS support in ResourceLoader". It includes implementing bugzilla:46546 (languages like SASS or LESS in debug mode), and then one or both of bugzilla:46545 (SASS) and bugzilla:40964 (LESS).

This post was posted by Mattflaschen, but signed as Superm401.

Good! Assuming that the maintainers are ok with this. Please write a more explanatory description under Raw projects. Thank you!

This post was posted by Qgil-WMF, but signed as Qgil.

I've added details at Mentorship_programs/Possible_projects#SASS.2FLESS. Let me know if more information would be helpful (some additional info is at the linked bugs). I also linked there from the SASS and LESS bugs.

This post was posted by Mattflaschen, but signed as Superm401.

I could also probably mentor this project as well if needed.

Hello, I hope I am not writing in the wrong place. I am a student(4h year in Department of Informatics, University of Athens) interested in Gsoc and would like to apply for a project in wikimedia. On this page: http://www.mediawiki.org/wiki/Summer_of_Code_2013 (Incremental data dumps -> https://bugzilla.wikimedia.org/show_bug.cgi?id=28956 and especially this post: http://www.mediawiki.org/wiki/User:ArielGlenn/Dumps_new_format_%28deltas,_changesets%29 ) I have found an interesting subject that I have some experience with. Is this still open, because on this page I don't see it anywhere? My experience on this issue come from my involvement recently in the Sigmod 2013 Programming Contest, where we faced many similar issues. The competition was in C++ but the theoretical background is similar and XML-Python will definitely not be the problem I imagine. If this project is not available any more, it would be really helpful to point me towards something else available and similar. I have strong skills in C,C++,Python,Java,Web Languages(JS,CSS,PHP,HTML) and the ability and time to learn anything else needed.

Hello Sibetheros! The best place to ask is indeed bug 28956. You can also contact Ariel directly (who coincidentally or not happens to be a fluent Greek speaker) via IRC or email.

This post was posted by Qgil-WMF, but signed as Qgil.

Many of the ideas listed at Mentorship programs/Possible projects are too generic ("Write an extension"), improvements of existing features ("Improve Extension:CSS") or work-in-progress tasks ("Fix Parsoid bugs"). Many others are not directly related with development, and therefore are not suitable for GSOC.

After this filtering, we seem to be left with:

• Create a VisualEditor module
• Article evolution playback tool idea
• Write an extension to support XML Sitemaps without using command line
• Extension:OEmbedProvider
• Add support for x3d 3D files to MediaWiki
• Allow smoother and easier Wikimedia Commons pictures discovery
• Build an interwiki notifications framework and implement it for InstantCommons
• Automatic category redirects

(If you think your project should also be considered here please speak up!)

Most of these projects seem to be extension (and PHP?) centric. Can we have more diversity? Maybe gadgets and templates are too simple for a GSOC project? What about the mobile front? Do we have skin development projects that could make it here? Anything in the DevOps area? Anything the MediaWiki core maintainers would like to see happening?

It would be also nice to have more candidates benefiting specific Wikimedia projects. Beyond Wikipedia, we have several proposals related to Commons. Wikidata seems to be joining soon. What else? Could this be a chance to help Wiktionary, Wikibooks or any other project with specific needs craving for tech attention?

Also to the many students that have already showed their interest: feel free pushing your project ideas now!

This post was posted by Qgil-WMF, but signed as Qgil.

Writing a VisualEditor plugin (e.g., "write a plugin to let users edit sheet music visually in the VisualEditor" or "…source code…" or "…poems…" or "…timelines…" or …) are an option that (a) didn't make your list, and (b) are written in JS, not PHP. :-)

JD that is somewhat similar to what I was wishing for. I do know that wikis are missing visual addition of music aspects. I am not sure where Extension:Score is currently situated but I know that it is sitting in bugzilla, and I would like to see something that will also work in and out of VisualEditor. So someone thinking about music in general, and then the aspects now and future. Long wished for, long resident in bugzilla.

Well, a Score editor would potentially be an immense project unless there's an existing JS editor out there that saves into Lilypond; so far all I've been able to find save into ABC…

VisualEditor plugins are now the first project idea officially proposed. Your edits to improve Summer_of_Code_2013#Project_ideas are welcome.

I would be happy to add a mention to Parsoid as long as we have also a specific proposal, a mention to the skills required and confirmation that there would be a mentor for this.

I will continue adding sections today. Stay tuned.

This post was posted by Qgil-WMF, but signed as Qgil.

I removed "An easy way to share wiki content on social media services." Let's avoid projects based on proprietary APIs, at least in the context of GSOC.

This post was posted by Qgil-WMF, but signed as Qgil.

It occurred to me that an inline comment tool could be a powerful extension to MediaWiki, particularly (but certainly not solely) for readers. See bugzilla:46440 and this EE thread.

This post was posted by Mattflaschen, but signed as Superm401.

Not to cookie-lick this (;-() but this is somewhat in the scope of the VisualEditor's rough plans for 2013/14; I'd love to work with someone on GSoC (or otherwise) on building something like this, though!

I love you.

Interesting. I originally suggested it for AFT, but clearly it would work well with VisualEditor (either using the VE API I've heard about, or built-in to the extension proper). I've CCed you on bugzilla:46440.

I have offered to act as a mentor should the project move forward. However, it looks like GSOC allows more than one official mentor (and of course we can have unofficial mentors too), so it would be great to have you or someone else from the VE team.

This post was posted by Mattflaschen, but signed as Superm401.

Happy to help out. :-)

This proposal has an own entry now: Mentorship_programs/Possible_projects#co-ment-like_tool_for_inline_comments. Looks good to me, and I'm willing to add it to the GSOC page as soon as we have a potential mentor or two...

This post was posted by Qgil-WMF, but signed as Qgil.

Two questions - what's wrong with being php- and/or extension-centric? MediaWiki is written in php, and its main strengths lie in its modularity - its extensions - so shouldn't a lot of these ideas involve one or both of those?

And if we have new ideas, where exactly should we add them? Since you've already picked through the main list, that doesn't seem an appropriate place to put them, but nor is a discussion. Is there a wiki page or section available specifically for GSoC project ideas anywhere?

Mentorship programs/Possible projects is still the pool of possible projects. Please add new ideas there.

This post was posted by Qgil-WMF, but signed as Qgil.

Nothing wrong with PHP and extensions, but there is more diversity of technologies under the Wikimedia umbrella and it is good to put some effort in promote it. This increases the quantity and diversity of students that we can reach effectively.

This post was posted by Qgil-WMF, but signed as Qgil.

Two bugzillas that regularly get prodded, and have plenty of history are around ...

• Extension:Cite which has a talk page full of issues that could do well to be updated, especially considering we now have Lua, so seeing that interaction work a whole lot better, AND the ability to have other tags work inside <ref> would be fantastic.
• bugzilla:18861 failing searches due to not expanding transcluded pages prior to indexing, such that any cross namespace transcluded pages are missed by our internal searches, so this means templates, and for the Wikisources, many of their proofread pages.

GSOC is mostly about developing new features. Ports and bugfixes stand little chance, regardless of how important they are.

This post was posted by Qgil-WMF, but signed as Qgil.

Ok, let me answer better. Fixing a piece of software might qualify as a GSOC project as long as there is a big task defined that would keep a student busy during 12 weeks. Pointing to a list of minor/normal issues is not an option, and this seems to the the case of Extension:Cite.

bugzilla:18861 is a High/Major bug assigned to Ram, who is a full time WMF developer. Not a good candidate for a GSOC project.

This post was posted by Qgil-WMF, but signed as Qgil.

frankly, as a general user/editor this seems all wrong -- how better to learn how to work on software than to actually work on existing software, with all its legacy flaws and issues? Cleaning up extension:cite, or any other highly used extension, will impact way, way more people than any of the stand-alone projects I see on the list. It might be harder to mentor and triage, but it seems like small stand-alone projects are often not so useful. Maybe this is part of the Google requirements (that you can't use the students as free labor) but I'd imagine most of these big extensions are pretty big intellectual challenges too, especially when considered as part of a system (around citations, or whatever).

I'm just saying that we can't tell students at Summer of Code 2013 to go through a talk page full of issues that could do well to be updated. Can you write down a paragraph describing what are the main problems of Extension:Cite and the impact it would have to fix them? Can you involve the Extension:Cite maintainers to make sure they agree and will be willing to take the work done by a GSOC student? Yet another question would be to make sure that there is someone willing to mentor this task.

Our main priority is to propose at the Summer of Code ideas that have the main pieces in place. Possible Projects page will be just one click away. This Talk page will be two clicks away. And they can come up with projects that are not listed anywhere.

This post was posted by Qgil-WMF, but signed as Qgil.

well, Extension:Cite wasn't my idea (it was posted by that IP) and I'm not sure what's wrong with it, so I can't answer your specific questions :) In general though maybe I'm just confused about what y'all are imagining as student projects. On the main page, under the guidance, "NO to variations of existing features" and "NO to projects done in a closet that won't survive without you" seem like they might be contradictory in practice, as many major needs do already have some kind of related features.

It isn't easy to write a simple generic statement covering all cases.  :)

If we make a specific decision that you consider wrong, please tell how we could do better. Right now I'm specially interested in projects we propose / discard for Summer_of_Code_2013 because that is the page that needs to be ready by Thursday. For all the rest we have extra weeks to discuss (including new projects that could be proposed).

This post was posted by Qgil-WMF, but signed as Qgil.

I've boldly changed the phrasing to prohibit *trivial* variations on existing functionality. I agree that substantial improvement in existing functionality is a reasonable project -- that's what Robin did last year, for instance.

I would love to see the watchlist system fixed so it can support categories.

TWISI, There should be two levels or options for watching a category:

1. being notified whenever a page either adds or removes the watched category
2. being notified for any change in a page belonging to the category.

currently, watching a category basically means you'll be notified for any change to the category page itself, which is not what a reasonable person would expect when they add the category to their watchlist (of course, after some experience most of us realize that watching a category is useless. there are some gadgets floating around that will add all the pages in a category to the user's watchlist, but this is not what i'm talking about above).

it is my understanding that such projects were stated and then abandoned (i might have misunderstood), and i think there are some extensions that try to address the category/watchlist junction, but as far as i saw, none of them did "The Right Thing" ™.

peace.

Thank you, these are interesting suggestions.

"Being notified whenever a page either adds or removes the watched category" is bug 7148.

"Being notified for any change in a page belonging to the category" is bug 1710.

Both old requests with clear support but stalled. Interesting! I will comment in those reports to make a reality check.

This post was posted by Qgil-WMF, but signed as Qgil.

you might also want to to peek in Extension:CategoryWatch.

it is my impression that this extension is stale, and in any event i do not think it should be an extension - this is core functionality.

i also don't think the extension functionality is complete.

peace.