This could also potentially be done as a separate extension.

See http://lists.wikimedia.org/pipermail/ee/2013-March/000263.html (beginning of thread), in particular http://lists.wikimedia.org/pipermail/ee/2013-March/000276.html (about some of the UI/UX challenges).

The AFT team is not planning on implementing this, at least for the time being.

It is a candidate for a Google Summer of Code Project (mentioned at https://www.mediawiki.org/wiki/Talk:Summer_of_Code_2013#List_of_project_ideas_25327), among other possibilities.

Regadless of Wikipedia & Wikimedia plans, this looks like an extension that would be useful and welcomed in other MediaWikis out there. Well, I know that in the GPLv3 drafting times I really wanted to have that in the MediaWiki based project we were running...

Then again it is not a trivial project at all. If we propose this we should put apart key aspects of Wikipedia like 5.000 editors commented on the same sentence, performance issues, scalability... Perhaps the project could consist in recycling as much stet code as possible and plug it to a MediaWiki backend.

(In reply to comment #3)

Then again it is not a trivial project at all. If we propose this we should
put
apart key aspects of Wikipedia like 5.000 editors commented on the same
sentence, performance issues, scalability... Perhaps the project could
consist
in recycling as much stet code as possible and plug it to a MediaWiki
backend.

But why would that many people be commenting on the same thing? There are only so many parts of an article worth commenting on, and only so many points to be made, and a flat out discussion would belong on a talkpage (or equivalent), not in the comments themselves.

As it is people tend to distribute what they work on and edit. Yes, many, many people edit wikipedia and such, and a lot of people may edit the same article, but it doesn't happen all at once. Comments, even if they do span multiple revisions, will only span so many before they cease to apply.

Just look at gerrit as a tiny example - plenty of folks comment on plenty of things, but I've rarely seen more than one or two people comment inline on any one patchset. It's only useful for so many things, and once someone made a point there's no use making it again.

If it's not the problem, all the better. I'm just saying that we shouldn't hamper this potential GSOC project with Wikipedia-centric issues if they are not issues for the 98% of MediaWikis out there.

Right, I guess my point was just that wikipedia is not as extreme as folks often make out, sorry. If the thing is well-engineered and scales properly it should work for everyone, which would be perfect.

(In reply to comment #4)

But why would that many people be commenting on the same thing?

Think of a controversial article that asserted a true, verifiable, but controversial fact. It would probably perennially attract comments to the sentence stating the fact. So at the very least there would have to be easy filtering/mark as resolved/mark as rejected.

I agree it doesn't *have* to be Wikipedia-scalable, but it's certainly far more useful if it is.

Note, implementers should also consider looking at the co-ment code.

Such articles tend to be protected on some level, though, and the same reasons would probably have to apply to this as well.

This sounds much more like a separate extension than an enhancement to ArticleFeedback.

This feature request is being considered for

https://www.mediawiki.org/wiki/Summer_of_Code_2013#Project_ideas

Question: is there a potential mentor willing to help potential students interested in this project?

A bit of context and braindumping:

http://openannotation.org/
http://www.openannotation.org/wiki/index.php/Web_Page_Clients_List

Maybe "annotations" is the label we are looking for? Wikipedia articles are not scholarship texts, and inline comments won't be scholrship annotations. Then again... aren't they structurally the same? Point to a specific portion of text and connect a comment, a signature, a timestamp, maybe a link.

Another aspect is My Annotations, as part of My Contributions.

I guess annotations will need a unique deeplink?

And do we get those annotations by default, or should users activate an "Annotated view"? Maybe the latter, it looks like too much extra bytes and clutter for the majority of people interested in the first paragraph and some factoids.

Bonus:
Are all annotations willing the be seen publicly by default? We won't go for private annotations, but maybe people want to have notes-to-self? Like ToDo post-its for editors, or notes for students preparing their school work. Those would be as public as our User pages: public for those knowing where to look but out of default searches / views.

To follow up, I have decided to act as mentor should the project be selected.

I think annotation is a valid term, although comment is also commonly used (e.g. LibreOffice, Google Docs). co-ment seems to use both terms.

There should probably be some kind of permalink that shows the comment, but initially that might just be a link to the revision (especially if comments aren't preserved on edit in the first implementation).

I don't think they should be shown to readers by default. It would have to be a toggle of some kind. It would be nice to make this available in VisualEditor mode (either just that, or both).

The notes to self idea needs further thought. I see the primary use of the extension as collaborative work, but then again people do use userpage for drafts too.

If this project moves forward, we may want to continue speccing it out on mediawiki.org.

James Forrester has indicated that this may be within the scope of VisualEditor, and that he would be receptive to the feature being implemented as part of GSOC. I've CCed him.

More context:

Commons has annotations in images:
http://commons.wikimedia.org/wiki/Commons:Image_annotations

Munaf mentioned annotations at
http://www.mediawiki.org/wiki/Micro_Design_Improvements#Annotations

I've linked this bug from https://www.mediawiki.org/w/index.php?title=Feature_map&diff=663816&oldid=566850 where the FSF feature was reported.

(In reply to comment #11)

Are all annotations willing the be seen publicly by default? We won't go for
private annotations, but maybe people want to have notes-to-self? Like ToDo
post-its for editors, or notes for students preparing their school work.

Looks outside the scope of the request. It's indeed the sort of thing the word "annotation" is usually used for, so let's not call this proposal "annotations" maybe?

So, to my mind there are two options here, and I can't quite understand which is being discussed (it appears both):

• Is this about surfacing to the editors in some nice way post-VisualEditor roll-out the existing comments for editors - I.e. "<!-- PLEASE DO NOT CHANGE OBAMA'S NAME -->" at the top of the Barack Obama article on enwiki? If so, great, and this should probably be moved to the VisualEditor product space. This is definitely needed for VE, but I worry that the scope for functionality is not huge, and it might be limiting.

• Is this about building an additional persistent/semi-persistent un-threaded/semi-threaded discussion space on top of pages/revisions(?) like Co-ment and Google Docs? If so, that sounds fun, and something that we're also looking at building for VisualEditor (as part of the real-time collaboration system, potentially), but I wouldn't want us to get in the way of someone building a first pass for GSoC. Doing this for both VE and wikitext at the same would be a really hard UI challenge (they're very different interface concepts), so perhaps limiting it to just one of them for now? Also, there needs to be a really serious discussion about how this would work from a product perspective (threading? how much? how signed? using LQT? why not? where stored? attached to revisions? To pages? to sections of said revision/page? how? etc.) lest it become mammoth. OTOH, this would be very cool as well.

Apologies for the confusion on my part. :-)

From where I'm coming from, it has nothing to do with the first option (HTML comments/warnings to editors).

It is meant as a collaboration tool, essentially your second option. I don't see it as a replacement for long free-form discussion ("this article needs more reliable sources..."/"it has an undue weight is the following areas"...), but a targeted form of collaboration around small areas of the article, like co-ment.

I agree a first pass (on MediaWiki.org, etc.) would be useful regardless, even if not all the code could necessarily be integrated into the permanent solution. It would allow trying out implementations and UI ideas.

I agree it would probably have to be one interface at first (and maybe ever), and VisualEditor/Parsoid probably makes more sense.

There would probably have to be limited threading, but flat (these people commented on this excerpt in this chronological order) would probably be sufficient. If it gets too elaborate, talk it to the talk page/Flow.

To keep it concise, I would suggest just the username and date (perhaps auto-formatted to e.g. "3 hours ago" for recent comments), rather than a signature. I suggest it should show IPs for anons.

I'm not envisioning using LQT, since it seems like if we want to integrate at some point, Flow would be a better candidate.

It would be most useful attached to pages, automatically invalidating a comment when an excerpt is altered. But "attached to revision" is probably more realistic for the first implementation.

This is the end result we are after:

Wikipages optionally looking like this (famous examples picked for reference only):

http://gplv3.fsf.org/comments/lgpl-draft-1.html (few comments)

http://gplv3.fsf.org/comments/gplv3-draft-2.html (really busy)

That view would include the possibility to add comments. There is a sandbox to play without registration at

http://www.co-ment.com/see/

And a lite version at https://lite.co-ment.com/

PS: group permissions to be taken into account? Maybe not in a prototype for a GSOC student but I can imagine that the same levels of protection (open, registered users, autoconfirmed...) would be desired. For Wikimedia wikis I would require login, a nice reason to register. But this is going too far... :)

Also, spam check? Posting external URLs possible or not? Well, this can be endless and again we should define the scope for a GSOC prototype.

http://okfnlabs.org/annotator/ is maybe (with some adaptations) a relevant option.

(In reply to comment #19)

http://okfnlabs.org/annotator/ is maybe (with some adaptations) a relevant
option.

Also http://hypothes.is (they seem to build on top of okf's annotator: https://github.com/hypothesis/h#development)

Slightly related: http://homes.cs.washington.edu/~travis/reflect/

With old MediaWiki extension code available: http://www.mediawiki.org/wiki/Extension:Reflect

Depends on LiquidThreads, so I don't expect many possibilities of reuse as-is but perhaps you want to have a look.

Just a note to say that Richa Jain has submitted a GSoC / OPW proposal related to this report:

https://www.mediawiki.org/wiki/User:Rjain/Proposal-Prototyping-inline-comments

There is another student that has submitted a proposal. I will announce it here as soon as there is a public URL.

ganeshaditya1 wrote:

Hey,
My name is Aditya and am interested in pursuing this as my GSOC project.

After going through the requirements, leaving apart any additional features required. I have outlined two major aspects of this project.

1. Designing the UI.
2. Designing the database.

I just want to present my perspective on these two things before I start drafting my proposal. I want to hear your opinion on this.

1)UI
When it comes to designing the UI. I think it will be better if we go with a custom build rather than using a ready-made component, cause MediaWiki uses themes and each component should match the theme and a ready made component leaves very little margin for customization ( in-case its a opensource component, then it might as well be modified, but the person designing the theme need to be not only versed with the code of the MediaWiki but as well as the source code of the component, hence I believe a ready made component would constrain the customizability of MediaWiki.

http://adityasastry.in.cp-2.webhostbox.net/index.php?title=Special:BlankPage
This is a UI mockup I came up with. Its a prototype for a prototype :P I have made an implementation of this for VECTOR theme, but I have placed the CSS and JS for this in the common skins shared.css and the JS in vector.js as of for now.
Implementing this for some other theme is very easy. We just need to add a DIV in the theme's php file.

ganeshaditya1 wrote:

2)Databases
Allow me to make a very bold statement here that json/xml are ill suited for a project of this nature.
Justification:

1. There are many helper classes already written for MediaWiki like sanitizer class(which depends on the databases) load balancer class(Incase one wants to distribute the comments data) and few other classes which implement functionality which is critically needed. Incase one wants to go the XML/JSON way one needs to implement them as well.

2. Maintenance will become an issue.

3)When migrating between hosts one needs to manually select the xml/json files and move them around. MYSQL supports one click export and import functionality for all the tables.

I will be making a prototype for databases as well in a couple of days.
And here's my idea. Each article is stored as a WikiText string, so as illustrated by my UI the selected text's starting and ending indexes are caught and the article page name is also caught. These three attributes will be used as indexes into a table "Comments"

When parsing this wikitext, based on the starting and ending indexes the text will be marked and a link will be provided next to it to access the comments as I have shown.

I will be implementing this functionality by tuesday. But for the sake of proposal I will be not using any of the MediaWiki classes for now so you people could test drive it once and based on your feedback I will be making ammendments to my proposal, so please review my work so far :)

(In reply to comment #23)

Hey,
My name is Aditya and am interested in pursuing this as my GSOC project.

Thank you for your interest.

Implementing this for some other theme is very easy. We just need to add a
DIV in the theme's php file.

Note that this is being proposed as an extension. Thus, you should not need to modify the core skin definition.

ganeshaditya1 wrote:

I seem to have butt into the conversation .. I didn't read the comments yet.
Apologizes ..

Anyways keeping with the conversation, since you guys are discussing interfaces, please checkout my prototype

http://adityasastry.in.cp-2.webhostbox.net/index.php?title=Special:BlankPage

Instead of the in-page along with article display, I would propose a movable popout as the readability might suffer when you try to squeeze in the comments interface into the article.

Just a note to say that Anthony Chen has submitted a GSoC proposal related to this project: https://www.mediawiki.org/wiki/User:N3c/GSoC_Proposal

Another tool for inspiration? http://www.thepund.it/

Java backend but "The Pundit client is a Javascript application based on the Dojo Toolkit http://dojotoolkit.org/ . It works closely with the Pundit server API, allowing the end-user to annotate any kind of web contents."

Apparently related with Europeana and funded by the EU. Sounds like open source but after a very few clicks couldn't find sources (busy day etc).

ganeshaditya1 wrote:

going a little off topic here, I think internet explorer cannot be supported in any efficient way, cause of the way text ranges are implemented in it.

Both ofkn and pundit are not supported in IE. I ve been going through the code of OFKN for a while now and this dawned upon me just now.

(In reply to comment #29)

going a little off topic here, I think internet explorer cannot be supported
in any efficient way, cause of the way text ranges are implemented in it.

Both ofkn and pundit are not supported in IE. I ve been going through the
code of OFKN for a while now and this dawned upon me just now.

In the VisualEditor project we have similar needs for cross-browser range selection and manipulation, and we have used the Rangy library - https://code.google.com/p/rangy/ - which has worked out well for us. Not sure if this is helpful for you?

ganeshaditya1 wrote:

(In reply to comment #30)
going by the description, it perfectly fits the bill! I mean it has all the methods of firefox available in IE. But the documentation is really very poor man. Its going to take me a while to make heads and tails of this :(

Richa Jain has been accepted for Google Summer of Code for this project. She is currently investigating OKFN and the store plugin. The below are some thoughts as a starting point:

OKFN provides documentation on writing a plugin for storing annotations (https://github.com/okfn/annotator/wiki/Store-Plugin)? The most straightforward approach seems to be implementing that as a MW extension.

https://github.com/okfn/annotator-store is an example of how one store works, though of course the MW extension example will be different.

One issue is that the API is RESTful. It lets you set a custom prefix, but the syntax is a little different than MW normally uses.

One way to do this is to make a normal MW-style API subclass (like https://www.mediawiki.org/wiki/API:Extensions#Creating_API_modules_in_extensions), then hook into the URL routing code to translate the OKFN-style RESTful URLs to calls to the API.

Someone may have made a RESTful wrapper of a MW API, or have advice on doing so. It's probably also worth looking at the hooks (https://www.mediawiki.org/wiki/Manual:Hooks)

(In reply to comment #32)

Someone may have made a RESTful wrapper of a MW API, or have advice on doing
so.

I sure hope this exists. The API interface is terrible right now.

From Matt's email:

The high-level concept of RevisionDelete applies, but I don't think
directly using it is a good fit. What happens if one comment on a page
is a violation, but the next consecutive 999 are fine? With RevDel, I
think you'd have to remove the bad one, then suppress all 1000 (correct
me if I'm wrong) containing the bad one, leaving no history of how the
good 999 developed.

I was thinking one page per comment.

True, but there's existing code (the main one I'm thinking of is AFTv5)
to learn from. Another reason not to use a page is that it constrains
changes. Once we publish the JSON page, there could be bots that rely
on it, rather than the API. If we just use JSON internally, that gives
us flexibility.

If we use pages, we could still use JSON only internally. We'd implement a new Content type for annotations and still provide an API module for accessing comments.

All that said, I understand the concern with using articles as a storage medium, so I would be fine with either way. I just wanted to make sure we weren't ditching the idea without due consideration.

(In reply to comment #33)

(In reply to comment #32)

Someone may have made a RESTful wrapper of a MW API, or have advice on doing
so.

I sure hope this exists. The API interface is terrible right now.

I saw they allow overriding the URL syntax (https://github.com/okfn/annotator/wiki/Store-Plugin#urls), so the main concern is probably less used methods like PUT and DELETE, which needs investigation on both sides (OKFN and MW).

(In reply to comment #35)

I saw they allow overriding the URL syntax
(https://github.com/okfn/annotator/wiki/Store-Plugin#urls), so the main
concern
is probably less used methods like PUT and DELETE, which needs investigation
on
both sides (OKFN and MW).

AFAIK, if you submit a PUT/DELETE request to the API, it will probably just treat it as a GET request, although I could be wrong and have not tested this.

tilgovi wrote:

Just popping in to subscribe to CC on this. I'm actively maintaining and improving Annotator for Hypothes.is and am happy to answer any questions or work with you all to close any gaps we need to in order to store annotations in mediawiki.

Just a note that i have made a repo on github https://github.com/richajain/Prototyping-inline-comments and have done some initial commits. I will be updating this with the progress done at regular time.

Gerrit is ready and all my github changes are imported.
https://git.wikimedia.org/log/mediawiki%2Fextensions%2FAnnotator.git
The basic skeleton of where to call the annotations is ready. Now i am starting with the storage of comments. Here are some of my points:

1. Going through the idea of custom table implementation and storing comments in a separate table which takes account of the revision id, user and the range.
2. Creating classes 'create', 'update', 'read', 'delete' for annotations. https://github.com/okfn/annotator/wiki/store-plugin#urls
3. Modify the above urls of OKFN as:

prefix: 'api.php'
create: '?action=create', etc.

azaroth42 wrote:

Just to recommend the hypothes.is version of annotator, and to point to the Open Annotation specification for the implementation:

http://www.openannotation.org/spec/core/

and

http://www.w3.org/community/openannotation/

Hope that helps, and looking forwards to seeing the outcomes. Happy to answer any Open Annotation questions that may come up!

tilgovi wrote:

We're right here watching, Rob :)

I would recommend just focusing on upstream okfn/annotator. We're cranking hard to get everything relevant pushed upstream.

Richa, don't hesitate to reach out if you want help testing or have any questions about the annotator code.

See also:

• [[Wikipedia:Village_pump_(idea_lab)/Archive_3#Sticky_Notes_for_Easier_Editing]]
• [[Wikipedia:Sticky notes]]

I was wondering if someone from the OKFN team could answer a couple quick questions.

I'm a little unclear about the relationship of 'read' and 'index', and how the URLs work.

https://github.com/okfn/annotator/wiki/Storage#index says index returns "a list of all annotation objects". First, I'm wondering if that is supposed to be limited to the current page's annotations. Maybe that's up to us.

However, the plugin docs (https://github.com/okfn/annotator/wiki/Store-Plugin) have no mention of index, nor do I see a way to override the URL.

https://github.com/okfn/annotator/wiki/Storage#read says it's a straight-forward method that takes an ID and returns a single annotation.

But the plugin docs (Store-Plugin) say, "read: GETs all annotations. Called when plugin loads or .loadAnnotations() is called. Server should return an array of annotations serialised as JSON."

Looking at the Coffee code, it seems read is called to get a list, but never explicitly called for a single annotation (although there is a commented out line doing that). However, since we're using the recommended 303 redirect, it's implicitly used for creations.

The list part is confirmed by testing. It loads http://127.0.0.1:9090/w/api.php?action=annotator-read&id=:id, which is a bit weird. I think this is related to https://github.com/okfn/annotator/issues/186

It seems like this may be a moot point if we use loadFromSearch. However, I would expect there to be an 'index' url for consistency.

nick wrote:

(In reply to comment #43)

Hi all,

Sorry not to have weighed in earlier. I'm really glad to see you're using Annotator, and hope I can help out with any problems you might have.

I'm a little unclear about the relationship of 'read' and 'index', and how
the URLs work.

Yes, this is a bit messy. Read and index are implicitly the same endpoint at the moment, and index is just "read" with a null ID. Obviously this is horrible, but it turns out that it doesn't matter that much as an index endpoint that returns all annotations is almost never useful anyway, so...

It seems like this may be a moot point if we use loadFromSearch. However, I
would expect there to be an 'index' url for consistency.

...the vast majority of real implementations use loadFromSearch. If you're interested, current work in progress on Annotator 1.3/2.0 (http://github.com/okfn/annotator/compare/wip...master) is revisiting some of this stuff, and the four endpoints that need implementing by a store are now create/update/delete/query, and the index endpoint is gone.

But, to answer your concrete question: use loadFromSearch and ignore the existence of the "index" endpoint.

nick wrote:

That GitHub compare url has the sense of the comparison the wrong way round: http://github.com/okfn/annotator/compare/master...wip

We've made a Bugzilla component. This will still be the main bug, tracking the initial key functionality.

There is now a test wiki for this, http://annotator.instance-proxy.wmflabs.org/ . If you're interested in testing it, create an account, then try annotating http://annotator.instance-proxy.wmflabs.org/wiki/Lorem_ipsum .

Currently, you must be logged in, both to see annotations and to make them (bug 51722).

You can now also use the simpler URL, http://annotator.wmflabs.org

Just tried the demo and it works well. Great work Richa and mentors! Just a couple of comments:

• When I edited the page all annotations were gone, I reverted to the previous edition but the annotations didn't reappear.
• I assume that these annotations will be displayed in the newly deployed Visual Editor. Would it be possible to update the text anchor as the text is being changed? Annotations in Google Docs have this behaviour, however I am not sure if it would be too complex to mimic that feature.
• A minor glitch: when I delete an annotation I get the message "sorry we could not destroy this annotation", however the annotation is indeed deleted.
• In the "recent changes" page I didn't see any notification of my actions, I understand that it could be meant this way?

And I also loved that you can select several sections of text and create one annotation for all those sections. If the annotation link could be displayed (maybe with a 3rd icon, an anchor displaying the link), that would be a great addition for external websites linking to/highlighting particular fragments, or conversations in the talk page pointing to fragments.

Micru

(In reply to comment #49)

Just tried the demo and it works well. Great work Richa and mentors! Just a
couple of comments:

• When I edited the page all annotations were gone, I reverted to the

previous
edition but the annotations didn't reappear.

It looks for annotations for the latest revision since i am using the latest revision id. There is already a bug filed for this https://bugzilla.wikimedia.org/show_bug.cgi?id=51728 .

• I assume that these annotations will be displayed in the newly deployed

Visual Editor. Would it be possible to update the text anchor as the text is
being changed? Annotations in Google Docs have this behaviour, however I am
not
sure if it would be too complex to mimic that feature.

• A minor glitch: when I delete an annotation I get the message "sorry we

could
not destroy this annotation", however the annotation is indeed deleted.

The destroying of annotations is still under review. https://gerrit.wikimedia.org/r/74150 so the annotations are not actually deleted currently.

• In the "recent changes" page I didn't see any notification of my actions, I

understand that it could be meant this way?

And I also loved that you can select several sections of text and create one
annotation for all those sections. If the annotation link could be displayed
(maybe with a 3rd icon, an anchor displaying the link), that would be a great
addition for external websites linking to/highlighting particular fragments,
or
conversations in the talk page pointing to fragments.

Micru

(In reply to comment #49)

Just tried the demo and it works well. Great work Richa and mentors! Just a
couple of comments:

Thanks. :)

• When I edited the page all annotations were gone, I reverted to the

previous edition but the annotations didn't reappear.

Yes, handling page changes is one of the trickier things that there may or may not be time for this summer.

However, we do want to fix the issue where the wrong annotations appear when you look at an old version of the page from the history (bug 51728).

• I assume that these annotations will be displayed in the newly deployed

Visual Editor. Would it be possible to update the text anchor as the text is
being changed? Annotations in Google Docs have this behaviour, however I am
not sure if it would be too complex to mimic that feature.

There is no VE support so far.

• In the "recent changes" page I didn't see any notification of my actions, I

understand that it could be meant this way?

We may have time to add logging, but you're right there is no history or logging yet.

And I also loved that you can select several sections of text and create one
annotation for all those sections. If the annotation link could be displayed
(maybe with a 3rd icon, an anchor displaying the link), that would be a great
addition for external websites linking to/highlighting particular fragments,
or conversations in the talk page pointing to fragments.

That's a possibility at some point.

GSoC "soft pencils down" date was yesterday and all coding must stop on 23 September. Has this project been completed?

There are two open patches right now:

https://gerrit.wikimedia.org/r/79839
https://gerrit.wikimedia.org/r/78251

Once they are merged, the extension has most of the features implemented. The only thing not implemented is threading, which would be too difficult because OKFN does not natively support it.

Yeah, I consider this complete. I think we will be able to get those two merged, but I don't think either are hard requirements (though the annotation tab is pretty useful, because otherwise you get annotations everywhere all the time).

As Tyler noted, there's not really reply support. However, if you comment on the same text, it puts the annotation underneath.

The other item that is not implemented (mainly since we did not prioritize it) is including the date.

However, there have been other items implemented that were not listed under Required Deliverables, so I think it balances out. E.g.

• Update and delete
• Proper DB setup (including AnnotationRepository for testability), including SQLite support and updates.
• Logged out user support (under review; Required Deliverables mentions usernames, but not IPs)
• PHP unit tests (this is the third change under review, which I would like to get merged).

swalling wrote:

(In reply to comment #54)

Yeah, I consider this complete. I think we will be able to get those two
merged, but I don't think either are hard requirements (though the annotation
tab is pretty useful, because otherwise you get annotations everywhere all
the
time).

I think bug 52064 is the only big UI/UX blocker for actually deploying this to a Wikimedia wiki. Showing annotations by default on every view is likely to annoy folks.

Otherwise, I think even things like bonafide threading support can be put on hold for later release. Overall, agreed with Matt that this product is nearly done. Very good work for a GSoC project. :)

Bug 52156 (history) is also a blocker (to be clear, this is an extra, not part of the required prototype deliverables) to WMF (and probably most third parties) deployment. It's not strictly UI, but it's definitely user-visible (to experienced users who understand history).

The GSoC project has the "Prototyping" word very visible. Wikimedia requirements for deployment are out of scope. The fact that they are being discussed already now indicates that this prototyping phase seems to be a success. :)

Let's get through the GSoC evaluation and let's talk about further steps after that.

tilgovi wrote:

Nice to see this worked out well!

As for replies, I've got a threading plugin that handles most of this. I'm looking to upstream it for Annotator 2.0.

I'll also take the feedback about not showing annotations immediately into mind. Nothing stops the integrator from overriding the .annotator-hl styles, but something more direct and programmatic might make sense.

Once again, reach out any time in #annotator on freenode or the annotator-dev list and I'll keep watching this bug.

If you have open tasks or bugs left, one possibility is to list them at https://www.mediawiki.org/wiki/Google_Code-In and volunteer yourself as mentor.

We have heard from Google and free software projects participating in Code-in that students participating in this programs have done a great work finishing and polishing GSoC projects, many times mentores by the former GSoC student. The key is to be able to split the pending work in little tasks.

More information in the wiki page. If you have questions you can ask there or you can contact me directly.

In T48440#529613, @Parent5446 wrote:

https://gerrit.wikimedia.org/r/79839
https://gerrit.wikimedia.org/r/78251

Once they are merged, the extension has most of the features implemented. The only thing not implemented is threading, which would be too difficult because OKFN does not natively support it.

In T48440#529622, @Mattflaschen-WMF wrote:

Yeah, I consider this complete.

So should this task be closed as resolved? (The item is mentioned on https://www.mediawiki.org/wiki/Outreach_programs/Possible_mentors - that's how I got here)