Closed Bug 665752 Opened 13 years ago Closed 6 years ago

Accept annotations / comments on wiki documents

Categories

(developer.mozilla.org Graveyard :: Wiki pages, enhancement, P3)

Product:
developer.mozilla.org Graveyard
Component:
Wiki pages
Type:
enhancement

Tracking

(Not tracked)

Status:
RESOLVED WONTFIX

People

(Reporter: openjck, Unassigned)

References

(
URL
)

Details

(Keywords: in-triage, Whiteboard: [type:feature][triaged][pm-wanted]) 

Support for threaded comments is not required.
Version: unspecified → Kuma
Assignee: lcrouch → nobody
Target Milestone: 1.0 alpha → ---
Priority: -- → P2
What is the rational behind this feature?

The PHP documentation has comments. It's a good way to complement the doc since it's not a wiki... but comments end up being way too long and hard to navigate when you have a particular issue. Sometimes, the comments are no relevant anymore since versions have changed.

Moreover, since Kuma is a wiki, people can edit the page directly or create a new page and link them together easily.

Additionally to the rationale, it's worth asking:
* Will the comments be moderated?
* Who will be doing the "garbage collection"?
Hey David.

This was an early idea for Kuma. I don't think much discussion has happened since then, so I'm glad you brought these points up.

I'm going to cc: some people from the team. What do you guys think?
I do want to have comments on articles, but I'd like to have the ability to delete individual comments or all comments. If comments are hierarchical (with replies to comments), the ability to delete a tree would be helpful.

My thinking is that we would want tools to help us use comments to improve the body of the article, instead of relying on comments as an addendum to the documentation the way many sites seem to do. Ideally, each comment would have a button to let readers vote to merge that comment into the body of the article. This would let editors improve the article from the feedback we get more easily.
I agree with Sheppy's points about voting and deleting.

Even though people can edit the wiki, some choose not to. They may be intimidated by the idea of changing *the* documentation, or they may know that something's wrong, but not know what the correct answer is.
There are also times when the best solution is elusive, resulting in the need for a discussion about it. Being able to do that on the page, come to a decision, implement it, then remove the discussion that led to the decision would be awesome.

Or maybe you just archive the discussion so you can refer back to it later if someone asks why the hell a change was made.
All good points. I'm afraid about deleting comments that people could get upset to see their comment here one day and gone the day after. Being able to archive parts of a discussion would be a good idea indeed.
I <3 the way djangobook.com does per-chapter and per-block comments:

http://djangobook.com/en/2.0/chapter02/

Extensive, yet unobtrusive.

This is for sure a Q2 or even Q3 feature though. :)
(In reply to Luke Crouch [:groovecoder] from comment #7)
> I <3 the way djangobook.com does per-chapter and per-block comments:
> 
> http://djangobook.com/en/2.0/chapter02/

Agreed; that's pretty nice indeed. I would still want the ability to archive and hide comments once the issue they bring up is addressed, to clear them out of the way once they're no longer relevant though.
Perhaps a "hide comments" feature, where an admin could set some comments to be hidden by default, but a user could reveal them to see the full context of a discussion, or ensure that their deathless comment prose lives on.
> I <3 the way djangobook.com does per-chapter and per-block comments

+1 on per-block comments. This is one of the things I loved most about a Mercurial book I read (http://hgbook.red-bean.com/read/how-did-we-get-here.html). However, I was always annoyed that it was impossible to comment on a chapter at large. My recommendation: per-paragraph AND per-page comments.

> I would still want the ability to archive and hide comments once the issue they bring up is addressed, to clear them out of the way once they're no longer relevant though.

I kind of like this idea. One of the problems with the Mercurial book is that there was no indication which comments were addressed, making conversations confusing. "Why is that person asking the author to fix the spacing? The spacing looks fine to me... Oh, it was already fixed." Hiding them completely might also make conversations confusing, so maybe they could be "collapsed" instead.
(In reply to John Karahalis [:openjck] from comment #10)
> > I <3 the way djangobook.com does per-chapter and per-block comments
> 
> +1 on per-block comments. This is one of the things I loved most about a
> Mercurial book I read
> (http://hgbook.red-bean.com/read/how-did-we-get-here.html). However, I was
> always annoyed that it was impossible to comment on a chapter at large. My
> recommendation: per-paragraph AND per-page comments.
+1
The Djangobook comments UI is just brilliant.
I was initially very doubtful on comments, but there realy are ways to get them right apparently. Switching side :-)
Blocks: 671902
Priority: P2 → P3
Whiteboard: [u: user] [c: wiki] → u=user c=wiki
I agree with David's original comments.

I feel as though the usefulness of comments will be little because:

1.  Monitoring them sounds like a full-time job, and even more time-consuming because local-specific stuff will take longer.
2.  We'll get loads of comments like "This is wrong" or "How do I do {x}" or "It doesn't work for me" -- all of which are useless
3.  If something is truly wrong, the user should edit the wiki, not buy a gem in the comments.
4.  Comments open us up to loads of SPAM.

Comments seem very counter-intuitive to a wiki.
Version: Kuma → unspecified
Component: Website → Landing pages
Merging bug 665753 into this. Bug 665753 is about disabling comments on a per-page basis.

It is still a feature that we should consider if we ever decide to build a commenting feature, but it does not need its own bug until we get to that point.
Same story with bug 665754. We might want to include that feature if we ever build a commenting section, but it does not deserve its own bug until then.
Component: Landing pages → Collaboration
Summary: Kuma: Provide a comments section at the bottom of every article → Provide a comments section at the bottom of every article
Whiteboard: u=user c=wiki
Same with bug 665756. We might want to allow comments to be edited.
Same with bug 665757. We might want to allow comments to be voted on.
Tweaking the title to reflect that we're probably not going to simply add a comment form to the bottom of every wiki document.

I think our sense so far is that a per-paragraph comment feature might be more interesting.
Summary: Provide a comments section at the bottom of every article → Accept annotations / comments on wiki documents
(In reply to Les Orchard [:lorchard] from comment #23)
> Tweaking the title to reflect that we're probably not going to simply add a
> comment form to the bottom of every wiki document.
> 
> I think our sense so far is that a per-paragraph comment feature might be
> more interesting.

Yes, I think the idea would be to let people, in essence, slap sticky notes onto the document that can be shown or hidden to let people exchange thoughts about what needs fixing through these notes, but keep them out of the way for people that just want to read the docs.
(In reply to Les Orchard [:lorchard] from comment #23)
> Tweaking the title to reflect that we're probably not going to simply add a
> comment form to the bottom of every wiki document.
> 
> I think our sense so far is that a per-paragraph comment feature might be
> more interesting.

Should this be merged into bug 852969, then?
Flags: needinfo?(lorchard)
(In reply to John Karahalis [:openjck] from comment #25)
> (In reply to Les Orchard [:lorchard] from comment #23)
> > Tweaking the title to reflect that we're probably not going to simply add a
> > comment form to the bottom of every wiki document.
> > 
> > I think our sense so far is that a per-paragraph comment feature might be
> > more interesting.
> 
> Should this be merged into bug 852969, then?

Yeah.
Additional detail in bug 665752.
Er, additional detail in bug 852969. Lots of good discussion there.
Flags: needinfo?(lorchard)
I have thought about this quite a lot, and read the different bugs and comment threads. I am still unconvinced that we need a in-page commenting feature for the Wiki.

A lot of the submissions for commenting systems of this type tend to be:

1. Requests to make trivial updates to the page, which they can just do themselves
2. Spam
3. weird off-base comments
4. vaguely related requests for support, such as "fix my code plz".

By having a wiki where you can't leave comments, you get people into the mindset of "fix it yourself", which is what we want people to do. As soon as you let people be lazy and start leaving comments asking others to do the work, I think you will open the floodgates to a whole world of pain and extra admin.

Even if you can have the comments hidden most of the time, it will still be a pain to navigate, get messy, and any gems may be lost.

In my opinion, a commenting system should be removed from the context of the article, to provide some separation and order to the process. We already have mailing lists for people to leave requests on, if they want to provide article feedback. But how about the following:

1. For each doc, we have a section or separate page along the lines of MediaWiki discussion pages, where you can record notes and ideas related to the article that you don't want to show on the actual article page. So for example, as I write new open web apps content, I want somewhere to record already existing articles that duplicate some of all content, so I can keep track of where everything is covered and start to merge/delete stuff. You could also use this page to record ideas of new code samples to add, or new sections that ought to be added.
2. You could have a separate forum for each doc, that just works like a regular forum. People can use this to suggest additions, link to useful related content, and ask questions. We should make the forum rules very clear - no generic support queries or requests for typo fixes.
3. We could have some flags available for people to use to request specific things, like "Needs code sample", "language review needed", etc.
I think we'd like something more discoverable and usable than MediaWiki talk pages, but avoid useless chatter like on this page: http://docs.webplatform.org/wiki/Main_Page

But I'd like to be able capture feedback like "I know something is wrong, because two articles have conflicting info, but I don't know what the correct info is." (This came up in IRC today.)
Agree with a lot of what Chris says. The overhead of managing comments could be overwhelming. We even have a good physical analogy for this.

http://mytko.org/random/desktop.jpg

In my opinion, a good middle ground would hide comments by default but make them available when truly desired -- when an editor is really, actively looking for a way to improve the article.

My podcast client takes this approach. It highlights new episodes, but only when I am looking for something to listen to. It never notifies me about new episodes. It never reports the number of episodes I have missed. The episodes are always there when I want them, but out of sight (and out of mind) when I have better things to worry about. Contrast this to the typical inbox or computer monitor post-it collection.
So John, you are suggesting to have a way of adding comments but keep them hidden from everyone except editors/admins, when they decide to reveal them? Or would everyone be able to see them if they so chose? Either wsy I think that idea has legs, and is worth exploring...

Another idea I had - to make the comments more discoverable but still keep them from getting messy, how about having a separate page for commenting/discussion, in which you can also vote comments up and down to have them appearing more or less prominently...but then having the most popular comments appear at the bottom of the article page in the same style as blog comments. With a clear link that says something like "To join the discussion about this article, go to the discussion page." ?
A project to keep an eye on, but it's not quite ready for prime time: Hypothes.is is an open source framework for online annotations
http://hypothes.is/what-is-it/
(In reply to Janet Swisher from comment #31)
> But I'd like to be able capture feedback like "I know something is wrong,
> because two articles have conflicting info, but I don't know what the
> correct info is." (This came up in IRC today.)
This is the sort of thing I wish to see captured to through bug 892916 (low barrier to entry message sent to either dev-mdc, a dedicated mailing-list or directly to relevant topic drivers)
I think an annotation feature has two main purposes:

1. To enable contributors to exchange notes and to collaborate on an article.

2. To allow readers to flag problems with the content when they're not sure of the best fix.

There's a third possibility, although it requires added code:

3. Allow readers to have private annotations, so they can take private notes on articles in order to keep notes about how an article relates to work they're doing, or while doing research.

I think as long as there's easy UI for nuking comments that are unruly or irrelevant (and maybe a spam filter supported on them?), the pros outweigh the cons.

I do not like the idea of comments separated from the content itself; I would vastly prefer something more akin to putting sticky notes to perform editorial flagging of the content in-place.
Tried an alpha version of Hypothes.is last night. Really incredible product. Even this early version addresses many of the features we have been discussing--including private annotations, spam control, and being unobtrusive by default--and the quality is unbelievable for a pre-release.

Highly recommend we consider using it to address this use case.
Spoke with Dan Whaley (copied here) of the Hypothes.is team today. He mentioned that we can start using the alpha version of the product today, though some obscure known issues do exist.

I will plan to try it out on some of our documentation as a way of beta testing longer-term integration. Anyone want to join me? You can install Hypothes.is by following the steps in [1] and can see a real annotation I added in [2].

[1] http://hypothes.is/alpha/
[2] https://developer.mozilla.org/en-US/docs/Web/JavaScript
I'm opposed to the idea of using this; it doesn't keep the information on our servers, meaning we're at the whims and fortunes of another organization and could lose annotations if they have a technical failure or their operation shuts down.

In addition, this requires the user to install an add-on or special bookmarklet code onto their computer. This is not an acceptable solution, even if it works great.

(I'm trying to set it up and so far have had several minor glitches, so it's taking a while).

Even if it works nicely, at best, this might be a model for what we want to implement, rather than an actual solution.
@sheppy 

1. The software is open source and annotations can be hosted by mozilla, we understand that many organizations will prefer this, and it's part of our strategy to support it.  we've purposely designed it to be neutral in interface (no branding) in support of that.

2. There's no requirement to have an extension or bookmarklet.  You can embed the javascript call in pages that you want to support annotation on.  For instance, here:
http://develop.dokku.hypothes.is/

3. This is still alpha software, so there are a few bugs we're working through.
https://github.com/hypothesis/h/issues?direction=desc&sort=created&state=open

Our goal is to build open tools that people use.  We're a non-profit.  Help us make it better.

:)
(In reply to Dan Whaley [dwhly] from comment #40)
> @sheppy 
> 
> 1. The software is open source and annotations can be hosted by mozilla, we
> understand that many organizations will prefer this, and it's part of our
> strategy to support it.  we've purposely designed it to be neutral in
> interface (no branding) in support of that.
> 
> 2. There's no requirement to have an extension or bookmarklet.  You can
> embed the javascript call in pages that you want to support annotation on. 
> For instance, here:
> http://develop.dokku.hypothes.is/
> 
> 3. This is still alpha software, so there are a few bugs we're working
> through.
> https://github.com/hypothesis/h/issues?direction=desc&sort=created&state=open

Ah! This wasn't clear from the stuff I'd briefly looked through. That's promising then.

I'll go back to waiting impatiently for the sign-up email to show up; been about an hour so far. These always take so long. I'm starting to suspect all the mail servers I use are hoarding them to make me crazy. :)
@sheppy checking the email situation.
@sheppy-- i've fired off two separate tests to @mailinator.com, both sent emails within seconds. Maybe try once more?
(In reply to Dan Whaley [dwhly] from comment #43)
> @sheppy-- i've fired off two separate tests to @mailinator.com, both sent
> emails within seconds. Maybe try once more?

It got caught by Postini; I always forget to look there instead of in my regular spam folder. :)
I've drafted an initial proposal for the annotation system. Please feel free to comment and improve it!

https://wiki.mozilla.org/MDN/Development/Annotations
URL: https://wiki.mozilla.org/MDN/Developm...
The Hypothes.is codebase, while using a Python backend written in Pyramid, is more heavily a front-end application. We're working to improve the Annotator (https://github.com/okfn/annotator) code base, upon which Hypothes.is is based, to make it more of a framework and the Hypothes.is UI more of a set of plugins for this framework.

It is fairly trivial at this point to use your own authentication system if you choose to host the API backend yourself. There is a backend written with Flask (https://github.com/okfn/annotator-store) that we use, slightly modified, at Hypothes.is, but it would also be possible to re-implemented fairly quickly on top of django models, if that's desirable.

The Hypothes.is team will be at MozFest. I would love to spend some time with anyone there who wants to take a crack at this.
@sheppy: I second Randall's thoughts above.

Also, I've annotated your proposal, specifically your requirements list, with links to the relevant issues on our roadmap / issue database.

Grab the extension or bookmarklet here to view:  http://hypothes.is/alpha
(And annotate away.)  

Also, our roadmap:  https://github.com/hypothesis/h/wiki/roadmap

It's important for us to be able to satisfy this kind of use case.  Help us build software you can reuse.

Dan
(In reply to Dan Whaley [dwhly] from comment #47)
> @sheppy: I second Randall's thoughts above.
> 
> Also, I've annotated your proposal, specifically your requirements list,
> with links to the relevant issues on our roadmap / issue database.
> 
> Grab the extension or bookmarklet here to view:  http://hypothes.is/alpha
> (And annotate away.)  
> 
> Also, our roadmap:  https://github.com/hypothesis/h/wiki/roadmap
> 
> It's important for us to be able to satisfy this kind of use case.  Help us
> build software you can reuse.
> 
> Dan

Good stuff. I'd be curious to see what the dev team things of this, but I know they're pretty swamped right now.
Whiteboard: [type:feature]
Whiteboard: [type:feature] → [type:feature][triaged]
Severity: normal → enhancement
Component: Collaboration → Wiki pages
Whiteboard: [type:feature][triaged] → [type:feature][triaged][pm-wanted]
Would it make sense to prioritize this feature in the short- to medium-term future? We seem to keep coming back to the idea without prompting. This could be a truly organic improvement to MDN.

Hypothesis also appears to be a very strong match for our needs. When we discuss commenting features (whether in this bug or in person) the requirements we name often line up with features provided by Hypothesis. Not necessarily /the/ solution, but certainly a strong enough match that it shouldn't be hard to get the ball rolling.
Flags: needinfo?(hoosteeno)
I'm happy to help however I can. (Disclaimer: I work on Hypothes.is).

We've been experimenting with the W3C for WebPlatform.org. They've deployed the FxA account and profile server there for testing and we're most of the way through a Single Sign-On solution where the Hypothesis annotation sidebar and MediaWiki both receive authorization from the FxA OAuth gateway. Our codebase is in a state where it's easy to add other authn/authz providers. Having experimented myself with Persona I can say it'd be trivial to support for that.

Probably what's needed to get the ball rolling is some requirements write-up so we know how the UI should be. Depending on the UI requirements, Hypothesis may be appropriate, or creating a custom AnnotatorJS application might be more appropriate. We're working hard to release an Annotator 2.0 this summer, which will make it easier to accommodate custom UI and storage requirements.
The question is who will curate the comments?
(In reply to Jean-Yves Perrier [:teoli] from comment #51)
> The question is who will curate the comments?

Certainly a valid question. You could pursue any avenue you like. If I asked in return, "Who curates the content?" you would say, "Well, everyone! It's a wiki." So maybe one obvious answer is to similarly allow anyone to edit or delete comments.
I think we should not go forward with this. It is not in the goals of the content team for the next months. We need to be sure that dev works on useful things for us.
(In reply to Jean-Yves Perrier [:teoli] from comment #53)
> I think we should not go forward with this. It is not in the goals of the
> content team for the next months. We need to be sure that dev works on
> useful things for us.

I still think this is an important long-term goal, and that rather than drop it entirely, we should just put it on the list of things to consider again at a later time.
If this becomes a priority I have several ideas for how we could make annotations an easier way to get user participation, improve the quality of the articles, and not require curation. (I do not know if Hypothes.is could support these.)

I would like to put together user flows and wire frames to explain but I won't do it if this is not a priority. 

Adding myself to the cc list to keep me in the loop :)
I like this idea a lot. It's not on our near-term development roadmap for the wiki. I agree with comment 54.
Flags: needinfo?(hoosteeno)
I do think this is something that could totally revolutionize our engagement with MDN users, and help to make even "non-contributors" into contributors. Probably would enormously help drive us toward the goal of having a larger number of members.
(In reply to Stephanie Hobson [:shobson] from comment #55)
> If this becomes a priority I have several ideas for how we could make
> annotations an easier way to get user participation, improve the quality of
> the articles, and not require curation. (I do not know if Hypothes.is could
> support these.)
> 
> I would like to put together user flows and wire frames to explain but I
> won't do it if this is not a priority. 

Stephanie, feel free to reach out with any questions. We'd love to help.
This is something we're now looking at implementing as a side project, detached from the main Kuma work, using a browser add-on. This would enable contributors to collaborate without impacting readers or the dev team, which has a lot to do already.

A proof of concept simple setup was demonstrated at our Berlin gathering, but I wonder if Hypothesis is compatible with this notion of an addon based annotation/commenting system that would share annotations with anyone else that has the addon installed.
> A proof of concept simple setup was demonstrated at our Berlin gathering, but I wonder if 
> Hypothesis is compatible with this notion of an addon based annotation/commenting system 
> that would share annotations with anyone else that has the addon installed.

This is exactly what we've built.  It's also available to embed on pages, or as a proxy.  (Paste a link on our home page to see an example).
I'm hoping to get (In reply to Dan Whaley [dwhly] from comment #60)
> > A proof of concept simple setup was demonstrated at our Berlin gathering, but I wonder if 
> > Hypothesis is compatible with this notion of an addon based annotation/commenting system 
> > that would share annotations with anyone else that has the addon installed.
> 
> This is exactly what we've built.  It's also available to embed on pages, or
> as a proxy.  (Paste a link on our home page to see an example).

I'd be really curious to see how that could be made to work -- if we can build something as an add-on, it would save our dev team a ton of work and we'd still get a major feature that a lot of people are outright begging for.

I'm pinging Andre Garzia, who was doing the prototype add-on in Berlin, to get his thoughts.
Flags: needinfo?(andre)
Glad to help. Dan, can you please point me to more information about Hypothesis, I don't know if I have the current links.
Flags: needinfo?(andre) → needinfo?(dwhaley)
(In reply to andre from comment #62)
> Glad to help. Dan, can you please point me to more information about
> Hypothesis, I don't know if I have the current links.

Andre: http://hypothes.is/
Flags: needinfo?(dwhaley)
Yep, that was the link I had. I checked their github repo and apparently there is code there to build a Firefox extension. Even if that is just placeholder code we could make an extension quite easily by reusing code from their bookmarklet. As far as I checked, it is as easy as loading a remote js in the context of the loaded page.

Couple questions that we need to sort our before pursuing this are:

1 - Do we want to host our own "h" server or are we going to use hipothes.is one? There requirements are described at https://github.com/hypothesis/h/blob/master/docs/INSTALL.rst I am not a docker expert and if we decide to host our own then we need to pass this back-end task to someone who knows what they are doing.

2 - User log-in. Apparently Hipothes.is has its own login system. I don't know if we want to go with this or if we want to fork it and try to add persona/firefox accounts/ldap/whatever support to it.

Both questions are related to backend because I think the extension is so easy to do that there is a chance I can solve that in a day.
(In reply to andre from comment #64)

> 1 - Do we want to host our own "h" server or are we going to use hipothes.is
> one? There requirements are described at
> https://github.com/hypothesis/h/blob/master/docs/INSTALL.rst I am not a
> docker expert and if we decide to host our own then we need to pass this
> back-end task to someone who knows what they are doing.

Yeah, we would want to host our own for various reasons. What we would do is spin it up on AWS. Once we get to a point where it's a production product, we can hand management off to the ops team, but for starters we can experiment.

Docker doesn't look too hard to deal with. We can handle that.

> 2 - User log-in. Apparently Hipothes.is has its own login system. I don't
> know if we want to go with this or if we want to fork it and try to add
> persona/firefox accounts/ldap/whatever support to it.

This is the one down-side to not implementing it as part of MDN's innards. :)

Ideally we would support the same services for login that MDN does, but I doubt that's realistic. We should probably try to do Persona (or Firefox Accounts, I suppose).

> Both questions are related to backend because I think the extension is so
> easy to do that there is a chance I can solve that in a day.

Yeah, other than the login part, I think a first alpha stage version of this thing is not a difficult project. But the logins are going to take some doing.  :)
> This is the one down-side to not implementing it as part of MDN's innards. :)
> Ideally we would support the same services for login that MDN does, but I doubt that's realistic. We should probably try to do Persona (or Firefox Accounts, I suppose).

Renoir Boulanger integrated with persona for the W3C Hypothes.is implementation visible here:
http://www.w3.org/TR/annotation-model/

I notice that his notes for the Hypothes.is portion of the Webplatform SSO documentation are a little skimpy, but I'm sure either he or @tilgovi would be willing to advise.
https://docs.webplatform.org/wiki/WPD:Projects/SSO

From Andre:
> Yep, that was the link I had. I checked their github repo and apparently there is code there to build a Firefox extension. Even if that is just placeholder code we could make an extension quite easily by reusing code from their bookmarklet. As far as I checked, it is as easy as loading a remote js in the context of the loaded page.

The firefox extension is something we're interested to finish--it's close. Any help here is appreciated.
WebPlatform.org is actually integrating with Firefox Accounts, not Persona.

However, the API we have internally for customizing sign-in is based on the Persona API. The sidebar code itself is an Angular application for which an identity service that mimics the Persona API handles the auth lifecycle.

Angular has what it calls providers for instantiating services. A provider is the configuration point for a service.

Integrating Persona into Hypothesis would look something like this:

angular.module('hypothesis.persona').configure(function (identityProvider) {
  identityProvider.checkAuthentication = function ($q) {
    // call navigator.id.watch() and return a promise resolving after the callbacks
  };

  identityProvider.forgetAuthentication = function ($q) {
    // similarly with navigator.id.logout()
  };

  identityProvider.requestAuthentication = function ($q) {
    // similarly with navigator.id.request()
  };
});

Alternatively, since the identity service's API _is exactly_ the watch/logout/request API, it might be simpler to override the whole identity service and just provide nagivator.id.

Anyway, we can modulate the details if we find any of it painful, but the gist is that I designed our auth code to integrate flexibly with different sign-in solutions and I took a lot of inspiration from Persona.
So... I want to start working on setting up the h server on an EC2 instance so we can work on testing. I have docker installed and running, but I know there are dependencies which I want to be sure I install correctly. Anyone available to chat at some point to make sure I get it right?
You can generally find devs in #hypothes.is on Freenode or our mailing list: mailto:dev+subscribe@list.hypothes.is.

Would be happy to help. ElasticSearch is the only hard requirement.

If you enable the accounts system (default is enabled) then you need a SQL database. Although Postgres is recommended and the only database we support for the accounts, SQLite can work for testing.

Redis is used for distributed sessions, if you need it, but that can also be done with cookies only.

NSQ is needed if you want to websocket features to work across multiple nodes, but is otherwise not needed either.

Let us know on Github or IRC or the dev list if you run into any troubles or questions. Documentation is, as you know, always an ongoing process.
Sheppy,

Can you create the repo so that I can fork it and start adding the plugin code.

Randall,

Besides injecting the scripts, can you tell me what other features the Google Chrome version of the plugin has?

Thanks a lot friends. Sorry for the delay. My plan is to start with a plugin talking to hypothes.is and then branch it to talk to our own server.
Flags: needinfo?(randall.leeds)
Flags: needinfo?(eshepherd)
Only two things different about the Chrome plugin:

1) User can toggle it per tab, and it stays across navigation. Not applicable here, since it's the publisher doing the embedding.

2) It bundles PDF.js so that we can let Chrome users annotate PDFs. Probably not applicable here, either.
Flags: needinfo?(randall.leeds)
I am starting with a generic Hipothesis plugin then I will fork it and fine tune it to our own use case.
Hey, there is already a Hypothesis Firefox add-on at https://github.com/hypothesis/h/tree/master/h/browser/firefox it does not work so I am patching it.
I've got the general purpose extension running. I am having trouble with the deactivation part. Right now, the extension loads the script from Hypothes.is which injects scripts and nodes into the DOM. 

If the user toggles the extension off using the button on the toolbar, I remove the added DOM nodes and globals but I can't remove the event handlers from BODY and DOCUMENT because I don't have references to the functions. If I don't remove the event handlers and the user toggles the extension back on then we end up with duplicated handlers so all annotations happen twice or thrice if the user does this another time and so on...

A solution to this is to do a tab.reload() upon deactivation but it will cause all the user input on the page and the current state to be lost which is a bad user experience. Imagine the user filling a form then accidentally switching the annotator on and then off and loosing his input.

I need help removing the event handlers, I could do that by cloning nodes but since they are attached on DOCUMENT and BODY it would end up removing all the handlers from the page including the ones not set by Hypothes.is. A solution would be for their script to keep references for all the functions added as event handlers in the annotator global they use, this way we could iterate over them removing what was needed before deleting the annotator global var. This would of course require help from Hypothesis to patch the embed script.

Any feedback or advise?
Flags: needinfo?(randall.leeds)
Andrew, I ran into similar problems when building the Hypothes.is Firefox extension (originally).

I'd be very happy to work with you to make it work (better / for real)! :)

Also, do join the mailing list Randall mentioned or pop into #hypothes.is on irc.freenode.net

I'm also available as `bigbluehat` in several Mozilla IRC channels (ping me in #introduction if that's easiest).

Let me know how I can help!
Andre, I'm sorry I didn't see this sooner.

You can call `window.annotator.destroy()` and that should take care of everything. If there are elements or event handlers left over after that please report it as a bug to us.
Flags: needinfo?(randall.leeds)
Just a note that we'll be at MozFest this year in the Science track if anyone wants to get together and say hi.
Status: NEW → RESOLVED
Closed: 6 years ago
Flags: needinfo?(eshepherd)
Keywords: in-triage
Resolution: --- → WONTFIX
Product: developer.mozilla.org → developer.mozilla.org Graveyard
You need to log in before you can comment on or make changes to this bug.