Social sharing for MDN pages

RESOLVED FIXED

Status

Mozilla Developer Network
General
RESOLVED FIXED
4 years ago
11 months ago

People

(Reporter: Janet Swisher, Unassigned, Mentored)

Tracking

Details

(Whiteboard: [specification][type:feature])

Attachments

(3 attachments)

(Reporter)

Description

4 years ago
What problems would this solve?
===============================
Promote awareness, generate pageviews and inbound links, and increase prestige of MDN members externally to MDN.

Who would use this?
===================
Anonymous and logged-in users could share any page. Logged-in users could share pages after saving updates.

What would users see?
=====================
"Share this article" option on any page.

After clicking "Save Changes", users would see a "Share your changes" option.

What would users do? What would happen as a result?
===================================================
Choosing the option would give the opportunity to share the URL on some set of social networks. 

Default text for the "Share your changes" option would be something like "I just updated [link,title] on MDN". After the appropriate authentication dance, the message would be posted on the selected social network.

Is there anything else we should know?
======================================
There may already be a bug for this, but probably not for the "share your changes" idea.
(Reporter)

Comment 1

3 years ago
Kate is a good person to talk to about tools to use for social sharing.
Just let me know how I can help :) I'm not sure of any tool that specifically addresses this need that we're currently using but I am exploring, with the User Engagement Team, the possibility of utilizing Social Raid (http://socialraid.com/) or getting a contract Expion (http://www.expion.com/) in Q3. In addition, our program's landing page is implementing a Twitter feed so visitors to the site can see real-time updates. As far as being able to share directly from a site, I believe this would need to involve the Privacy team as I'm not sure what kind of data will be shared with the platform they are sharing on. CC'ing Michaela above who also has a breadth of knowledge on this subject.
Looks like we could use https://github.com/mozilla/SocialShare/ like we do on Hacks for the first "Share this article" feature.

As for sharing changes, that might need something else/more.

:davidwalsh - what do you think here?
Flags: needinfo?(dwalsh)
Created attachment 8397121 [details]
NewSocial.jpg

This is what I'd like to do for my site.  No tracking and very simple.  Thoughts?
Flags: needinfo?(dwalsh)
Cool. Until this is prioritized, I'll make it a mentored bug in case someone wants to take it on.
Whiteboard: [specification][type:feature] → [specification][type:feature][mentor=groovecoder]

Comment 6

3 years ago
Is this still under development?
It's still a good idea, but we haven't decided *how* to add it to the pages. 

Might need a quick review from :habber on :davidwalsh's https://bugzilla.mozilla.org/show_bug.cgi?id=875062#c4.
Flags: needinfo?(hhabstritt.bugzilla)
This is a great idea and I definitely support doing it in the 2 places that Janet mentioned. On the articles themselves and for editors after making an update. 

On Mozilla.org we use our "Share This" widget. I'm unsure if we can make it look like David's example in #c4 since it requires the user to click on a "Share this" link before exposing the social channels.

See a post on the mozilla blogs to see how it works. (screenshot - http://cl.ly/image/3Y3A2e0R1e3P)  
https://blog.mozilla.org/webdev/2014/04/02/enabling-communities-iterating-on-the-get-involved-page/

This is what has been vetted with the privacy team. Craig would know more about the extent that we can modify this. 

(In reply to Luke Crouch [:groovecoder] from comment #7)
> It's still a good idea, but we haven't decided *how* to add it to the pages. 
> 
> Might need a quick review from :habber on :davidwalsh's
> https://bugzilla.mozilla.org/show_bug.cgi?id=875062#c4.
Flags: needinfo?(hhabstritt.bugzilla) → needinfo?(craigcook.bugz)
The sharing widget uses the standard JavaScript-embedded buttons provided by Twitter, Facebook, and Google+. Any customization of the buttons will be dependent on the options their respective APIs provide. I'm not sure the treatment in David's screenshot is possible in a privacy-respecting way, but I could be wrong. It would entail some way to hook into all three remote APIs that a) complies with their API usage requirements, b) respects user privacy, and c) gives us complete control over the appearance of those buttons.

Getting the count of how many times a URL has been shared means telling Twitter/Facebook/Google what the URL is, and if that happens on pageload I assume the request is sending other identifiable information as well (it certainly does with the standard buttons). The sharing widget just avoids sending the request until the user makes a deliberate action (opening the menu), rather than sending the request automatically on pageload.

We have very little control over the appearance of the standard buttons. We're just linking to a script hosted by the third parties, and each script in turn renders the button, usually in an iframe with all kinds of ugly markup around it, so we can't do much to change their appearance with CSS on our end.
Flags: needinfo?(craigcook.bugz)
FWIW, my screenshot and what I will be using on my site are simple window.open links, not an official widget of any service.
(In reply to David Walsh :davidwalsh from comment #10)
> FWIW, my screenshot and what I will be using on my site are simple
> window.open links, not an official widget of any service.

How are you getting the share counts? Is that data available from their APIs without loading a widget?

Facebook did have a passive sharing form that accepted a link with a query string but it was deprecated. With Twitter I believe you can still link to twitter.com with a query string to pre-compose the tweet, but they discourage that (and may have officially deprecated it by now, I could be wrong). I don't know about G+. I admit I haven't read up on any of these sharing APIs lately so maybe they all offer more methods of getting data without leaking user info back to the mothership.
Getting them all via JSONP, and I know that the Twitter API is deprecated.  IMO, the counts are vanity metrics which don't need to be there.
(In reply to David Walsh :davidwalsh from comment #12)
> Getting them all via JSONP, and I know that the Twitter API is deprecated. 
> IMO, the counts are vanity metrics which don't need to be there.

Oh they're absolutely vanity metrics and serve no real purpose (one could say they encourage more sharing because they indicate a page's popularity maybe, but that's grasping). 

If we can make links that share passively without loading anything from a third party (or just fetch third party data without sending any user data) then we can do whatever we want, stylewise.
(Reporter)

Comment 14

3 years ago
Does it make any difference in privacy if the counts are collected but not displayed to users? I think it would be useful to have metrics about what pages are shared most often on what services. But I don't see that as an essential part of the user-facing functionality.
Making any client-side request to twitter.com or facebook.com allows the 3rd-party site to track the user on our page. So, we hide those requests behind a user intention to share the page on social media.

If we hit their API's or endpoints from the backend we don't need to send any user data to the 3rd-party services to get the counts. But I don't see any API doc's that explain how to get that data via backend, and hacking something up probably violates API terms of use.

We could try an A/B test to learn if displaying the counts actually increases sharing activity.
Any idea how/where we want to present this now?  It will be easy to implement and has a big upside!

Comment 17

3 years ago
(In reply to Janet Swisher from comment #14)
> I think it would be useful to have metrics about what
> pages are shared most often on what services.
At least Facebook and Twitter have ways to gather these metrics.
For instance, to know how many time the page https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Proxy was shared on Facebook and Twitter, go to 
* Facebook : https://graph.facebook.com/?id=https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Proxy (it's currently 4 apparently).
* Twitter : http://urls.api.twitter.com/1/urls/count.json?url=https://developer.mozilla.org/en-US/docs/JavaScript/Reference/Global_Objects/Proxy (14 now)

Not sure about how reliable these APIs are in the long term (at least the Twitter doesn't seem to be an official API).

Super worst-case scenario, it's always possible to get this data with a Casper.js script or equivalent.
(In reply to David Walsh :davidwalsh from comment #16)
> Any idea how/where we want to present this now?  It will be easy to
> implement and has a big upside!

Maybe this is something good for our new MDN developer/designer staffer to take on?
(Assignee)

Updated

3 years ago
Mentor: lcrouch@mozilla.com
Whiteboard: [specification][type:feature][mentor=groovecoder] → [specification][type:feature]
I like those numbers. Might also be another indicator for localizers to see which page is trending and therefore makes sense to translate. But sure we don't want to track anyone.

So, anyone wants to take this? If someone outlines some starting points, I can have a look, too.
Next step - :davidwalsh needs to decide: SocialShare [1] or simple window.open [2] links

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=875062#c3
[2] https://bugzilla.mozilla.org/show_bug.cgi?id=875062#c10
Flags: needinfo?(dwalsh)
1000% window.open
Flags: needinfo?(dwalsh)
I would like to see goals set for these before we implement them with a commitment to remove them if they are not being sufficiently used. (Something like, if they are used by less than 0.3% of users we remove them or if we get less than 2,000 visitors a month through shared links). 

Related: in an ideal world we append campaign tracking variables to the links before they are shared so we know how many users have arrived via shared links.
When discussing whether or not to include numbers keep in mind most of the time the number will be zero. I'd rather not display them, just have them available some other way.
(Reporter)

Comment 24

2 years ago
I've written up a requirements doc: https://docs.google.com/a/mozilla.com/document/d/1NgAl1uBpkzb4ZDqvNmy_oKqN0Mtg1uHUMh-9oJbK8kw/edit#

To KISS, I've omitted both the display of the tweet count and explicit sharing of edits.
Keywords: productwanted
Created attachment 8576941 [details]
Screen Shot 2015-03-12 at 15.01.32.png

The requirements are great Janet :) Nice to see a narrow scope to begin with. There isn't anything in there I disagree with. 

I've attached a mockup of where we might position the buttons on an article and what they might look like. This is just a start, we should A/B test the crap out of this ;)
David if I create a branch with the HTML and CSS could you add the JS to it since we'll mostly be re-using what's on your site already?
Flags: needinfo?(dwalsh)
Luke, could you have a look at deliverable #2 and think about how you'd like to track this in Google Analytics?
Flags: needinfo?(lcrouch)
It may depend on implementation. If JavaScript, we can use trackEvent [1], like so:

mdn.analytics.trackEvent{
  category: 'Share',
  action: 'click'
}

The event is recorded in GA with the page, so we'll know which page was shared.

If we use plain HTML links that open new windows to twitter.com, we are already recording those outbound links in GA. [2]

In either case, though, it's impossible for us to measure the "Share" clicks on twitter.com. :/ So we'll have to just measure our own clicks, and then potentially compare to periodic spot-checks on twitter.com.

[1] https://github.com/mozilla/kuma/blob/cef467b56701d0b0c321ee55eacd0ca94c63285b/media/redesign/js/analytics.js#L9-L51
[2] https://github.com/mozilla/kuma/blob/cef467b56701d0b0c321ee55eacd0ca94c63285b/media/redesign/js/analytics.js#L56-L88
Flags: needinfo?(lcrouch)
Whiteboard: [specification][type:feature] → [specification][type:feature][patchwelcome]
The specs on this are looking good. Opening it up to contributors who have energy/time to work on it. Leaving productwanted on it until it lands on a roadmap.
There is now a PR that includes everything except URL click tracking :)

MDN has bit.ly integration but the functions are currently generating bit.ly URLs not mzl.la URLs. To get this done quickly we could:
1) not shorten URLs, and not track them
2) use bit.ly URLs

Any preferences? Any strong desire to put this off 2 months until someone has the time to look into mzl.la shortening?
Flags: needinfo?(dwalsh)
Right now the suggested share is the article <title> plus URL. Example:
> <canvas> - HTML (HyperText Markup Language) | MDN https://developer-local.allizom.org/en-US/docs/Web/HTML/Element/canvas

I think we want to try to make this a little friendlier. To start the discussion I suggest:
> I found this article about <canvas> on MDN: https://developer-local.allizom.org/en-US/docs/Web/HTML/Element/canvas
Flags: needinfo?(jswisher)
How important is localization for this first trial period?
I take Comment 30 back! The mzl.la shortening is working on production, the API just doesn't like to do it in our local dev environments :D
> > I found this article about <canvas> on MDN: https://developer-local.allizom.org/en-US/docs/Web/HTML/Element/canvas

I would like to make it even more encouraging: "I learned about <canvas> from this article on MDN:..."

Comment 35

2 years ago
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/b277758c42ef311cc55dd60f13e3f0121fdd879c
bug 875062 - Add initial framework for social sharing on MDN

https://github.com/mozilla/kuma/commit/0db7a5177b6b0593bad4df1edab3e4c0af18c0dd
Bug 875062: Social Share - add styles

https://github.com/mozilla/kuma/commit/a5c240295e4a8b9031f5505ea8645b09f8433856
Bug 875062: Add URL shortening

https://github.com/mozilla/kuma/commit/77cb75c84479e3e3aabf0a114ff29e81160a1486
Bug 875062: resolving error with rebase

https://github.com/mozilla/kuma/commit/c8067e1aef2a6e92971b385a6a487b66ebe4a44d
Bug 875062: Updated wording for share text.

https://github.com/mozilla/kuma/commit/03b711a937a79899cded2787c8164df38216ec70
bug 875062 - move and update tests

https://github.com/mozilla/kuma/commit/1b87788115ba03ea965fdc331f0909e636db46d2
bug 875062 - gettext wrap the share_text in view

https://github.com/mozilla/kuma/commit/89455ed44eaff43f2449a2aba51a275d26150acb
bug 875062 - change medium to 'doc share link'

https://github.com/mozilla/kuma/commit/7de757d1710c770c831ba9be47705b28e3db3458
Merge pull request #3124 from groovecoder/social-share-875062

bug 875062 - Add initial doc sharing
This feature is enabled on production for super-user testing.

:jms, :hoosteeno - want to try it out?
I'm playing with this some and have thoughts...

First, I wonder if we could just go with the logos of each of the services instead of the logo plus text in each button. I don't know if that's better or worse, but the buttons as they are feel very bold to me. That's possibly just me.

Second, I do think it's worth considering looking for a way to have those available at the top of the page somewhere. Maybe smaller buttons right under the title? That seems like a good possibility: just little icon-only buttons there, and then maybe stick with the existing style at the bottom of the page.

Third, and possibly most importantly, I'm not a fan of the current default text. I think it should be made more focused on the recipient than the sender. Something like "Learn about X on MDN!" That way, it doesn't risk denigrating the knowledge level of the sender, but invites others in to join us in knowledge.
Created attachment 8580192 [details]
share_mock.png


> :jms, :hoosteeno - want to try it out?

I think the functionality looks good. 

There is something visually jarring about the buttons (echoes of comment 37) to me. They don't seem coordinated with our theme -- e.g. the only red thing on a very blue page is a Google+ button. I think the sharing button on the fellowship page[0] is closer (but not perfect) to matching our theme.

Regarding the default text and the placement on the page: These are optimizations better made with data. But I think we will get more data if we put the share buttons higher to start. What about a more tightly coordinated set of buttons under the right sidebar? I attach a mockup -- very rough, not great.

I apologize for not seeing the earlier mockup in time to suggest this earlier.

[0] https://developer.mozilla.org/en-US/fellowship
A second comment: Regarding the effectiveness of share buttons, we have a bit of data now from the fellowship page. 0.4% of visitors to the page have clicked that button. The content is different, so it's not a perfect experiment. But...
* It's 10x our current (organic sharing) and
* It's .5x the 1% target in the spec

If we were aiming for that 1% target on the fellowship page (we're not) I would say we need to look for ways to make that button more effective -- probably starting with pushing it higher.
IIRC, we have issues when trying to put things (:openjck - the edit button?) in the sidebar because some pages don't have a TOC.
Flags: needinfo?(jkarahalis)
We could put the buttons in the sidebar, but it would take more work. Bug 1124199 was rolled back when some problems were discovered in the implementation.
Flags: needinfo?(jkarahalis)
Under the left side bar is complicated. IN the left side bar might be more possible.
I think that our next step should be outlining 3 A/B tests we can run for placement and 3 A/B tests we can run for button design:

For location I suggest:
1) Top of the page under the title
2) Inside the right column TOC, at the bottom, if there is one on the page
3) End of the article (where they are now)

For button design I suggest:
1) Current design
2) Logo only, with no heading
3) A derivative of the fellowship design

I have concerns about what the current language says about the sharer's skill level but I disagree that the language should target the readers, I think making a tweet promotional rather than personal will cause fewer people to click through. I don't know how we test the language of the share text. I think we have to go live with something and see what kind of edits people are making to it.
Depends on: 1145630
I uplifted comment 43 to bug 1145630, which now blocks this one. Excited to see progress on this!
(In reply to Stephanie Hobson [:shobson] from comment #43)

> I have concerns about what the current language says about the sharer's
> skill level but I disagree that the language should target the readers, I
> think making a tweet promotional rather than personal will cause fewer
> people to click through. I don't know how we test the language of the share
> text. I think we have to go live with something and see what kind of edits
> people are making to it.

That's fair. I'm not sure what language will be most effective either. Just gut feelings, I guess.
(Reporter)

Comment 46

2 years ago
Since "TIL" (today I learned) seems to be a common idiom in netspeak, my contribution to the bikeshed is: "Today I learned about <blah> on #MDN: <link>". People can shorten than to "TIL" if they want.
Flags: needinfo?(jswisher)
Keywords: productwanted
Whiteboard: [specification][type:feature][patchwelcome] → [specification][type:feature]
:groovecoder, can you share preliminary data on this with us?
Flags: needinfo?(lcrouch)
The first data coming back, from Apr 16 to Apr 22:

158 clicks to share; 47% Facebook, 29% Google+, 23% Twitter [1]

Top 10 shared pages [2]:

1.	
/en-US/docs/Security/Weak_Signature_Algorithm
14(8.86%)
	
2.	
/zh-CN/docs/Web/JavaScript/Reference/Global_Objects/Array/concat
6(3.80%)
	
3.	
/en-US/docs/Mozilla/Projects/Rhino
5(3.16%)
	
4.	
/en-US/docs/Tools/Remote_Debugging/Debugging_Firefox_for_Android_with_WebIDE
5(3.16%)
	
5.	
/en-US/docs/Tools/Scratchpad
4(2.53%)
	
6.	
/en-US/docs/Web/CSS/border-radius
4(2.53%)
	
7.	
/en-US/docs/Web/Guide/API/WebRTC
4(2.53%)
	
8.	
/en-US/docs/Mozilla/Mobile/Viewport_meta_tag
3(1.90%)
	
9.	
/en-US/docs/Tools/Remote_Debugging
3(1.90%)
	
10.	
/en-US/docs/Web/HTML/Element/textarea	
3(1.90%)

14  (8.9% conversion) sessions came frame the 158 clicks to share. [3]

Sessions from social shares are good sessions too: 7 pages/session (vs. 1.79 avg) and 5:56 session duration (vs. 2:13 avg), 14.29% bounce rate (vs. 69.86%). Interesting to note that only 12% of sessions from social shares are new sessions (vs. 42% avg.). So, to date, the feature is working more as a referral -> retention feature than a referral -> acquisition feature?

[1] https://www.google.com/analytics/web/?authuser=1#report/content-event-events/a36116321w64965862p66726481/%3F_u.date00%3D20150416%26_u.date01%3D20150422%26explorer-segmentExplorer.segmentId%3Danalytics.eventAction%26_r.drilldown%3Danalytics.eventCategory%3ASocial Share%26explorer-table.plotKeys%3D[]/

[2] https://www.google.com/analytics/web/?authuser=1#report/content-event-events/a36116321w64965862p66726481/%3F_u.date00%3D20150416%26_u.date01%3D20150422%26explorer-segmentExplorer.segmentId%3Danalytics.pagePath%26_r.drilldown%3Danalytics.eventCategory%3ASocial Share%26explorer-table.plotKeys%3D[]/

[3] https://www.google.com/analytics/web/?authuser=1#report/trafficsources-campaigns/a36116321w64965862p66726481/%3F_u.date00%3D20150416%26_u.date01%3D20150422%26explorer-table.plotKeys%3D[]%26_r.drilldown%3Danalytics.campaign%3Ashare/
Flags: needinfo?(lcrouch)
Depends on: 1162998
Given http://moovweb.com/blog/anyone-use-social-sharing-buttons-mobile/ (tl;dr 0.6% of users use social media buttons on desktop and only 0.2% on mobile.), I wonder how much energy to put into this.

Do we have more data as of now? What is success of this feature?
No more data since https://bugzilla.mozilla.org/show_bug.cgi?id=875062#c48 because we disabled the feature until we sort out bit.ly/mzl.la account limits.
(In reply to Florian Scholz [:fscholz] (MDN) from comment #49)
> Given http://moovweb.com/blog/anyone-use-social-sharing-buttons-mobile/
> (tl;dr 0.6% of users use social media buttons on desktop and only 0.2% on
> mobile.), I wonder how much energy to put into this.

While we don't have more data, we also don't have much more work. The work remaining is to figure out bit.ly and then enable the most effective of the A/B test candidates, and then we can see how our own audience uses it (it may not be the same as the e-commerce audience Moovweb studied).
(In reply to Florian Scholz [:fscholz] (MDN) from comment #49)
> Given http://moovweb.com/blog/anyone-use-social-sharing-buttons-mobile/
> (tl;dr 0.6% of users use social media buttons on desktop and only 0.2% on
> mobile.), I wonder how much energy to put into this.
> 
> Do we have more data as of now? What is success of this feature?

Comment 24 has a link to the requirements which includes success metrics (0.1%). It also includes goals for measuring if they increase the traffic MDN gets from social media. I am super curious to see our own results, in the very early findings of the A/B tests some of the combinations were out performing our goal. 

We are also measuring to make sure that it does not effect user's engagement with the articles and have made sure to avoid some of the common problems with social sharing (privacy violations and slower load times).

And, as Justin says, once the bit.ly problems are sorted out all we have to do is toggle a waffle flag.
Depends on: 1182210
Depends on: 1200659
After working at this code for a while, it's clear that using short links substantially increases the complexity of the feature. Briefly...
* We can't generate them for every request due to API rate limits; we need to store them in the database
* We can't generate the at request time and store them at that point, also due to API rate limits; we need to schedule generation and generate in the background
* We have to generate them for tens of thousands of documents at the start, and be prepared to generate them for large numbers of documents in the case of a move
* We can't generate short URLs for legacy documents in one big bang, due to API rate limits; we need to trickle out our generation of them in the background process
* We have to generate and store multiple links -- at least one per locale, since the slugs of articles are not consistent across locales
* Etc.

But surely all this engineering overhead is worth it? 

Actually, that's not assured. Threads on internal lists and questions in external forums have failed to surface a single compelling justification for using short links. Of course some social networks (Twitter) arbitrarily limit the length of social posts, but those networks apply their own URL shorteners to long URLs. And URL shorteners offer some analytical power, but we use Google Analytics and it works great. Yes, 2011 crowd wisdom says short links are better, but evidence of this is scant.[0] 

Conversely, there are reasonable arguments against using shortened links -- many feel they break the web in fundamental ways, and all would agree they obfuscate the destination of the URL. 

Considering all this, I would like to ship the social sharing feature without shortened links. It's a good feature; it's ready to ship; shipping it will immediately help MDN. We should not spend more cycles discussing or overengineering this feature to accommodate all the confounding factors.

I will close other bugs related to URL shortening and encourage the engineering team to release this feature with full-length URLs.

[0] http://webmasters.stackexchange.com/questions/85732/do-shorter-urls-really-outperform-longer-urls
See Also: → bug 1229884
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/13937d1e099b98564bfcd7f74154e2ed5164eefd
Bug 875062: Move share links to footer.

https://github.com/mozilla/kuma/commit/30a4eb4fe042e7eef1c1eb4b0ca11f68c6e406e3
Merge pull request #3697 from stephaniehobson/875062-share

Bug 875062: Move share links to end of article
We haven't seen the usage for these links that we need to meet our success targets. I consulted with Kadir and will be removing them.

The success targets in the requirements document from comment 24 was "shares per visit". I wasn't able to figure out how the initial number (0.05%) was calculated so I calculated it again so the comparison would be fair. I used the number of tweets with links to MDN from some records Florian has been keeping (thanks!) and divided them by the number of visitors Google Analytics reported in the same time period.

Oct   | Jan   | Goal
0.04% | 0.05% | 0.10% 

Some fun stats:
- Twitter was the most popular of the buttons
- 19 users per day arrive from links posted via our share buttons
- Share buttons are clicked 163 times per day

Comment 56

11 months ago
Commits pushed to master at https://github.com/mozilla/kuma

https://github.com/mozilla/kuma/commit/0e39a59cd6bebdae194ffce3e750fecdea3811be
Fix Bug 875062 - remove social sharing

https://github.com/mozilla/kuma/commit/ba14ff0ef4ed249f9208c3260119e4cc7e3e53ed
Merge pull request #3872 from mozilla/875062-social-share

Fix Bug 875062 - remove social sharing r=schalkneethling

Updated

11 months ago
Status: NEW → RESOLVED
Last Resolved: 11 months ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.