Firefox 43 new contributors

Josh Matthews

7 responses

With the release of Firefox 43, we are pleased to welcome the 46 developers who contributed their first code change to Firefox in this release, 35 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

Participation, yes and, community

Janet Swisher

The "Foxy" mascot is held aloft by attendees of the Mozilla 2013 Summit in Brussels

Photo by Marcia Knous


I’ve noticed that the terms “participation” and “community” have become more or less interchangeable in the context of Mozilla. I’ve even had a conversation with a Mozilla executive who said “I thought they were the same.”

It seems that the term “community” has been somewhat deprecated within Mozilla because it is ambiguous, in that it can mean different things to different people, which can lead to miscommunication. For example, some people use “community” as a shorthand for “volunteers” while others very intentionally use it to mean all Mozillians, paid and non-paid.

I see “participation” and “community” as related but distinct concepts, both of which are essential to Mozilla. Let’s start with definitions (sorry, I’m a word nerd). The Participation Team’s wiki page says:

Participation is when people can freely contribute their energies, time and ideas to support Mozilla’s mission.

So far, so good.

Here’s my generic definition of “community”:

A community is a group of people who interact and develop a network of relationships around a common factor.

The “common factor” is the wild card that leads to a wide variety of types of communities. If the common factor is physical location, the community can be a traditional geographic community. Some other types of communities include:

So, what kind of community is Mozilla? I consider Mozilla to be a community of action united by the Mozilla mission, which is the shared goal. Members of the Mozilla community take action (that is, participate) in order to realize that mission. However, Mozilla is really a constellation of overlapping sub-communities based on geography, interest, or practice. The nature of the sub-community determines the type of action that its members typically do. For example, a localization community shares a particular language, such as French, and its members take action by localizing software, websites, or documentation. A community for a functional area, such as QA, has some characteristics of a community of practice, but members focus on the practice of their skills on behalf of Mozilla.

Other key concepts in my definition of “community” are interaction and relationships. People who share a common factor, but don’t interact about it or have relationships with one another as a result, are not, for the purposes of this discussion, a community. (I know this excludes another widespread use of the word. That’s why I gave my definition.)

So, to bring the concepts together:

Participation is the “what” of the Mozilla community; community is the “how” of Mozilla participation.

Or rather, community, in my opinion, should be the “how” of participation. If people simply participate, but don’t interact and build relationships with others (that is, become part of a community), they are unlikely to sustain interest in participating over a more than, say, a few months. Therefore, when creating opportunities for participation, one needs to build-in opportunities for interaction, in order for the set of participants to develop into a community. When participants have relationships with one another, they are more likely to keep coming back to participate, making the group sustainable, that is, retaining more people than it loses.

Participation and community don’t necessarily go hand in hand; ensuring that they do requires careful design of participation opportunities.

The canonical example of participation in open source software is contributing a code patch. A programmer finds something that needs fixing, gets a copy of the codebase, fixes the bug, submits a patch for review, and ideally has the patch accepted into the main codebase. At the very least, this programmer has to interact with a reviewer. Ideally, she interacts with other members of the project earlier and more extensively than just at review time, through mentorship and discussion of the bug. She might also subscribe and post to a relevant mailing list, and read and comment on other bugs. Through these interactions, repeated over time, she becomes part of the community for the open source project.

However, not all participation opportunities have interaction built-in. For example, Mozilla Developer Network (MDN) is a wiki of developer documentation. Because it uses a pure wiki model, no review is needed for a change to go live on the site. It’s quite possible for someone to create an account and make many edits to the site without ever interacting with another human being. Such contributors are participating, but are not engaged with the MDN community. As community manager for MDN, one of my challenges is to draw contributors like that into communication channels such as mailing lists or IRC, and encourage them to interact with other members of the MDN community.

As your Mozilla team sets goals for 2016, with an eye towards inviting participation, I encourage you to also look for ways to invite and encourage interaction among participants, especially if open participation is new for your team. This could be as simple as creating a category on the Mozilla Community Discourse site, and encouraging participants to post there via welcome emails. Of course, make sure that existing team members initiate and respond to discussions there as well; they are part of the community, too. Communities don’t happen overnight, and they require (repeated, sustained) help in order to grow. The payoff is in sustained participation, as well as in the intangible benefits of relationships with fantastic Mozilla contributors.

Firefox 42 new contributors

Josh Matthews

1 response

With the release of Firefox 42, we are pleased to welcome the 41 developers who contributed their first code change to Firefox in this release, 26 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

Participation Lab Notes: Volunteer vrs Contributor

Emma Irwin

1 response

4773973784_8e249c98e7_z

As part of the Participation Lab’s efforts we recently began conducting  experiments on the Get Involved Page seeking to better understand how people navigate and connect (or fail to connect) to contribution opportunities. In preparation for this experiment we looked at some of the research that the Mozilla.org team had conducted in recent years, and a number of their  key learnings led us to a deeper conversation about the language and labels we use to invite contribution to Mozilla. Some of the those learnings were:

  • People need to understand what, and why before they’ll be interested in understanding how they can contribute to Mozilla.
  • We must make it immediately apparent that the Get Involved  page is seeking volunteers and not employees.
  • We need to set clear expectation of investment/journey needed to get involved or become a Mozillian.

This matched some other feedback,  and as a result we decided to conduct a series of interviews to discover more ideas and prejudices that exist around the terms volunteer and contributor. Eighteen interviews covering diverse perspectives were conducted, these included core contributors, project leaders, alumni, community project leads, those working in open science, advocacy and randomly selected people in my life who had never contributed to Mozilla.  We discovered four interesting insights shared below.

Project preference is ‘Contributor’

 

Overall, people working in, or already volunteering with Mozilla were more comfortable with ‘contributor’, but agreed that unless your background was working in a field like software engineering, or science where the term is already part of the language ecosystem, it might be challenging to grasp.  I also noticed  a trend in feedback that acknowledged  once you’re regularly involved  in a project you might no longer be objective, and that we may, in fact, be skewing even the most common understanding of these terms. One example given was the use of  ‘paid contributor’ and ‘volunteer contributor’, which made no sense for most people outside of Mozilla.

The term ‘Volunteering’ is more universally  associated with lending time and skills but…

 

While people seemed to generally understand that volunteering was about lending time and skills, I encountered sensitivities that the word ‘volunteer’ which invoked feelings of being ‘charitable’ vs the more empowered feeling of being a ‘contributor’ .  I heard that ‘contribution’ lends to a feeling we’re part ‘part of something ’ while ‘volunteering felt more detached.  One core contributor felt very, very strongly, that volunteering was not the term for what they do at Mozilla.

‘Contribution’ feels more like giving a gift or donation

 

Feedback from non-technical contributors ,and those I spoke with outside the Mozilla community indicated that  the term “contribution” was easy to misinterpret as being about donating funds or something of greater significance than some people felt they could offer.  When asked, a couple of people cited political campaigns, and fundraisers as the most common association they with the word ‘contribution’.

What’s in a Name?

 

It was also suggested that at Mozilla we should stop labouring over generalized terms like volunteer and contributor,  and instead focus  energies on clarifying ways people can help – One person felt that such opportunity  exists in more explicit ‘role titles’  i.e. Android Community Ambassador’.   The hypothesis is, that by providing role titles we can help people connect to opportunities that are resume-worthy with recognition that contribution is an opportunity.  Of course, there are already examples of success with role names demonstrated by the Mozilla Reps program and most recently Club Captains and Regional Leads in Webmaker Clubs.

Also..

We had an interesting suggestion that  we make up our own name!  Create a Mozilla-fied name for volunteers that makes volunteering at Mozilla a unique version of both terms.  An inspiring example was the London Olympics which called volunteers ‘Games Makers’, what a Mozilli-fied version would be remained unclear 🙂  but I’m sure we could come up with something.  What do you think?

Additional lure of a Mozilla-fied name is a chance to help people recognize the amazingness of the community they would be joining which MDN reported to be a factor in repeat contribution in their area  – and similar to how an Olympic volunteerism resonated with a name describing their impact.

So where from here?

 

There is the opportunity for continued experimentation and testing using the Get Involved Page, and  we would love to hear from you – contributor volunteer, Mozillia-fied name?

What experiment  do you think the Participation Lab should design  next with these new insights?

 

 

Image: “Mozilla Summit Day 2” by Roland Tanglaois licensed under CC BY 2.0

Meet an MDN contributor: klez

Janet Swisher

Photo of Frederico klez Culloca

Federico klez Culloca made his first few edits to MDN in 2013, but started contributing in earnest in 2014, as a localizer for Mozilla Italia. After a couple of months, he started attending the bi-weekly MDN Community meeting, and later the Learning Area meetings. After that, he concentrated his efforts on the Learning Area of MDN, especially the Glossary.

He says that working on MDN gives him a good idea of how an organization as big as Mozilla actually works, bringing together paid staff and volunteers.

His advice for MDN newcomers?

Don’t be afraid to make mistakes in good faith. Someone is always able and willing to correct them and help you learn from your errors. It’s a wiki, after all 🙂

Thanks, klez, for all your contributions to MDN!

Participation Lab Notes: The Power of Swag

Lucy Harris

It doesn’t take long, once you’ve entered the Mozilla community before you notice that swag is a big part of Mozilla. Stickers, t-shirts, lanyards are everywhere and for many Mozillians these things have become a kind of currency with emotional and physical value.

Photo by: Doug Belshaw on Flickr

Photo by DougBelshaw/CC BY 2.0

In 2014, Mozilla spent over $150,000 on swag to engage contributors across four major initiatives: Maker Party, MozFest, Mozilla Reps, and Firefox Student Ambassadors (FSAs).

However we rarely stop to examine what we are learning about the results, benefits and challenges of this investment.

In order to surface and capture these insights the Participation Team interviewed four groups at Mozilla, for whom swag is a core part of their activities, and identified the most interesting insights and challenges faced by each group.

As a result, we discovered that many of the groups face similar challenges but have found distinct solutions and strategies for managing them. The two major insights were that by encouraging local production of swag, and creating swag that is tailored specifically to the needs of the community, costs can be minimized and value to the community increased.

Maker Party

Although in the past year, swag has become a much smaller part of Maker Party as the campaign has become shorter (17 days vs. the previous 2 months) and more contained. In 2014 thousands of people spent the summer throwing events, and swag was an integral part of growing and motivating the Maker Party community.

Insight : Swag Legitimizes Hosts & Events

Much more than a form of recognition for event hosts, in many communities swag is perceived as a vote of confidence from Mozilla that legitimizes both the host and the event. Many communities feel that if we are willing to support an event host and their event through physical things, and it marks them as “officially sanctioned” by Mozilla and this alignment with the brand dramatically increases the influence and reputation of the contributor and the event.

For example, in South America, a Maker Party host created Mozilla branded mouse pads to legitimize their events in the eyes of local internet cafe owners who let them use the space for free in exchange for Mozilla branded mouse pads.

Challenge: Cost of Shipping

For Maker Party, shipping swag across the world, often to extremely remote areas, was very expensive and problematic. Certain countries charge enormous taxes on clothing and have been known to detain parcels with t-shirts – to the detriment of volunteers who often cannot pay the high customs fees.

MozFest

While MozFest, as a short-term festival is a bit different from the other examples,  it identifies another way in which we use swag to build and support community.

Insight: Swag is Key to Partnerships

Every year MozFest partners with other like-minded organizations to put on the event. As part of this relationship, partners are offered the opportunity to distribute swag and some promotional material to attendees. As a result Mozilla can produce a small amount of swag like a tote bag and water bottle, and have partners add their swag to create fun gifts for participants that also act as promotional pieces for partners and Mozilla.

Challenges: The Right Swag

Finding swag that is re-usable and has value outside of the event is challenging, but water bottles and tote bags have proven popular and effective, and have the added benefit of reducing the event’s environmental footprint.

Mozilla Reps

Unlike Maker Party or MozFest, Mozilla Reps is a community where individuals participate in multiple ways over a sustained period of time. For this group, it is often the variety rather than quantity of swag that drives excitement.

Insight: Creating A Collectors Culture

Within Reps, swag is a great way to acknowledge contributors and support events. However, in some circumstances, swag can come to be seen as a symbol that represents value and status in the community. Therefore as more of a swag item is produced the value of each item diminishes, and collectors culture has developed. While rare swag is a very powerful tool for driving engagement and recognizing achievement in the Reps community, it is important to be aware of the number and variety of an item that is produced, and to carefully manage expectations to prevent swag becoming an end in and of itself.

Challenge: Mitigating Expectations

As swag is a large part of the Reps culture, it is important to be careful about the expectations that are set around the value of swag. Limiting the kinds of official swag that is produced to t-shirts, stickers, and posters and having clear value attached to each, may be one way to keep expectations low and guard against increasing expectations.

FSA

The Firefox Student Association has many parallels in it’s structure and its relationship to swag as the Mozilla Reps program. However by carefully controlling the value of swag, and encouraging local production, many of the challenges faced by other groups have been avoided.

Insight: Careful Curation & Local Production

The FSA’s have solved problems related to shipping swag, and reduced the “freebee” quality by having FSA’s create their own swag locally and then be reimbursed for the cost. Like the Reps program they also have a collectors culture but set formal expectations on the “value” of different kinds of swag ie. t-shirts are something you have to earn, stickers are freebees you can give away at your event, and posters are something you have to produce yourself.

Challenge: Tracking Designs

Because unique designs are a large part of what gives t-shirt swag it’s value, there is a struggle to find and keep track of the many ways t-shirts and designs are being used across Mozilla. In order to coordinate the FSA program suggested creating a central repository of t-shirt designs and what/when they should be distributed so that the use of swag can be better aligned across all of Mozilla.

—

Overall, across Mozilla there is a great deal being learned and experimented with around swag as well as many areas for growth and improvement. Our hope is that by surfacing these lessons and insights, we’ll spark new conversations and gain more insights into the swag processes and how it can be improved. If you have experience or thoughts around swag at Mozilla please share them in the comments here, or on the Participation Team Discourse page.

MDN Fellows: What They Did & What’s Next

Diane Tate

1 response

It’s hard to believe our MDN Fellowship Pilot is winding down! Announced in May and oriented in June, our five Fellows and mentors have been heads’ down ever since.  Here’s a short summary of their accomplishments in the program and a taste of what’s next.

Curriculum (Steve Kinney, Fellow; Chris Mills, Mentor)

For the curriculum Fellowship we selected to write a full course on “Advanced beginning JavaScript.”  Steve and Chris considered this to be important because, while there are loads of resources looking at beginner-level stuff like variables and basic function usage + a load of discussion of really advanced techniques, there is very little to help a budding developer who has already mastered the basics and wants to level-up their skills.

Steve and Chris are still working on the course, and will be for weeks to come — see the repo, and read the index file for an idea of the content we’ll include.

If you want to dig in right away, you can already start working through some of the tutorials and demos.

Service Workers (Flaki Szmozsanszky, Fellow; Brittany Storoz + Anne Van Kesteren, Mentors)

With more widespread browser support for service workers fast approaching, we were aiming for creating a “baseline” service worker content kit. It was to cover the general, high-level “what are service workers and why should I care?” questions as well as being able to provide resources for interested parties. Take a test drive of the content kit here.

Beyond just collecting and completing the above baseline content kit, during the Fellowship Flaki had the chance to work closely not just with his service worker mentors Brittany Storoz and Anne van Kesteren but also with the content & platform teams at Mozilla who work hard on implementing service workers and related features in Firefox & Firefox OS.

We also devised a proof-of-concept transparent image format polyfill that uses service workers, which, besides being a novel approach in using service workers, helped a lot in uncovering some lurking bugs in Firefox’s preliminary implementation. We especially want to thank Ben Kelly of the platform team who was invaluable in tracking down, reporting and fixing those issues.

See this blog post for more details on the content kit and the proof-of-concept polyfill.

Test The Web Forward (Ben Boyle, Fellow; James Graham and Josh Matthews, Mentors)

As Test the Web Forward already has great documentation on getting involved, we had two goals: (1) address the quality of the contributions, and (2) build confidence in new contributors.

We’ve focused on understanding web specifications in order to write accurate tests both in terms of coverage (understanding the detail in a simple specification) and in challenging assumptions so that tests are based on what the spec says (and not what we think it means).

We’ve set up a codepen to use the testing framework. This can be forked to write new tests to check behaviour and is useful for exploring a problem, or for accompanying bug reports. It’s a nice quick way to get started, before installing the Test the Web Forward repo to contribute directly.

We are also working on a couple of case studies (more to come) showing the experience after finding an interoperability issue including researching the specs and analysing the behaviour seen in browsers. Each journey is different, and a wonderful chance to learn more about the web.

Web App Performance (Vignesh Shanmugam, Fellow; Harald Kirschner, Mentor)

With the increase in average website size, we need to better access the web from varying levels of computing power devices and experiments to show the impact on revenue with the increased load times – particularly during development.

The content kit that we are building helps web developers and others understand basic techniques for their websites to load faster. The focus is heavily on the network side of the performance since 70% of the time is spent on the network. Our Content Kit also has various beginner and advanced tutorials, slides and demos.

The kit is not complete yet. We are also planning to include lots of deep dive tutorials on understanding packet level information on TCP stack, how to leverage modern capabilities in browser etc. Please feel free to pour in your ideas.

It was an amazing experience to work with the fellows and mentors who are all part of the MDN fellowship program. Thanks to Mozilla for making this happen 🙂

 

WebGL (Greg Tatum, Mentor; NIck Desaulniers, Mentor)

It has been really exciting being part of the first Mozilla Fellowship group. One of the big reasons for my involvement with the web and open source communities is the feedback from my peers and the quick sharing and collaboration on ideas. The fellowship has quick-started my involvement with MDN and their enthusiastic team of staff and contributors. One of the most valuable experiences was being able to write an article for MDN and get immediate in-person feedback from one of the staff writers. It was really empowering to know that the docs I use every day are so easily improved.

I had a blast diving into explanations of some of the fundamentals of how you go from abstract data to 3D-rendered images in the browser. It was really helpful for my own understanding to build out content kits and articles that step through matrix math fundamentals, the 3d projection process, and finally getting to taking that data and lighting it.

I’m very passionate about creative coding and the technologies surrounding it. It still feels like a niche genre with a community that is growing, especially with people moving from desktop applications to web projects. I only want this community to get larger and produce more and more interesting works that inspires me. I hope my time spent with the Mozilla Fellowship and other open source contributions can help to continue to grow people’s knowledge and interest in technologies like WebGL.

Content kits

Shared utility library for WebGL explanations:

MDN Articles based off of the content kits:

…with Lighting Models coming soon

What’s Next?

We’ll be evaluating the role that this type of program might make towards the goals of both MDN and Mozilla overall. You also might see more contributions on MDN from our Fellows. And rumor has it you may be seeing some of this great work – and even contributing to it – at our November MozFest event in London.
Can’t get to London? Nothing’s stopping you from diving into those repos.

Firefox 41 new contributors

Josh Matthews

3 responses

With the release of Firefox 41, we are pleased to welcome the 62 developers who contributed their first code change to Firefox in this release, 51 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

Participation Lab Notes: Short Simple Tasks Increase Engagement

Lucy Harris

The Mozilla Participation Lab is an initiative that focuses on experimenting and surfacing new approaches to Participation. Read more about the Lab on our wiki page.

Every year, about 7 million people come to the contribute page on Mozilla.org looking for information about how to get involved with Mozilla. These visitors represent an exciting opportunity to increase the number of long-term relationships Mozilla has with people who are passionate about the open web.

Right now, however, only about 0.76% of those people ever register to contribute. Even once they’re registered, how we connect them to their contribution area of interest is far from optimized.

In partnership with the Mozilla.org team, the Participation Team has set out on a medium-term project to try and maximize the potential of this page. Our aim is to make it a better tool for potential contributors, Mozilla, and the mission.

This first experiment set out to figure out how to increase engagement with tasks presented to a visitor after they said they were interested in contributing. We designed and ran an A/B test over a few weeks, presenting visitors with different types of tasks.

tl;dr

  • we were able to increase the engagement rate to 60% (from 15%) in selecting tasks
  • visitors preferred simple tasks to challenging tasks, and shorter tasks to long tasks
  • presenting more options (6) versus fewer options (2) increased the number of people who chose to pursue a task

Keep reading to learn more about the results and the future iterations and experiments we have planned.

Experiment

In this A/B test we created four new versions of the contribute sign-up page. Each page presented viewers with a number of tasks categorized either as simple/challenging (variation a) or as taking a little time/more time (variation b). For each of these variations we displayed either 2 or 6 tasks per page.

Variation B : Simple vs. Challenging

Variation B : Simple vs. Challenging

Variation A : Little Time vs. More Time

Variation A : Little Time vs. More Time

For the purpose of this first test we did not track engagement past choosing the specific task, and we did not track engagement with individual tasks, measuring only the category of the tasks selected (eg. simple/challenging or little/more time).

Results

The major findings from this first round of testing were that visitors to the contribute page preferred simple tasks to challenging tasks, and shorter tasks to long tasks. We also found that presenting more options (6) increased the number of people who chose to pursue a task instead of selecting the “not ready” button. Finally across all of the page variations we found the percentage of people who engaged with the pages (either by choosing a task or selecting not-ready) was 60%, much higher than the 15% engagement rate of the original page.

Based on all of the results we can infer that majority of visitors to the contribute page prefer easier, low-barrier tasks, and prefer a handful of choices to just 2.

However there were still a minority of individuals who expressed a preference for more challenging tasks — they may represent skilled contributors who are ready to become deeply engaged in complex projects. In coming iterations of this experiment we will be exploring the level of readiness and skill of these contributors, and whether individuals from this group are more likely to become core contributors than those who selected simpler tasks.

Overall, the enormous engagement rate by both groups further supports the amazing opportunity latent in this page.

Next Steps

Over the coming months we will undertake several rapid iterations on this test. There is a great deal still to be learned, however we believe that through experimenting with participation in venues like this we can unlock huge potential to help people engage with Mozilla in high impact ways.

Over the next few weeks the Participation team will be working to design a second experiment and we will focus on:

  • Enhancing our understanding of the specific kinds of tasks contributors are most interested in
  • How the task completion rate varies among types of tasks and levels of difficulty and what this tells us about the contributors we are able to attract through this page
  • How wording and framing of tasks effects task selection and completion

Other topics we will seek to explore in the longer-term include:

  • Understanding best practices for how to setup second and third tasks to engage contributors in a more long-term way
  • How presenting localized tasks affects completion rate How to identify and present tasks with the maximum appeal to contribute page contributors
  • How to provide “off-shoots” for the non-typical contribute page contributors (such as those who want to contribute code)
  • How to increase the conversion rate from the homepage to the contribute sign-up page If, when and how to collect email sign-ups and what the process is for engaging contributors by email

This project is currently owned by Lucy from the Participation Team in conjunction with the Mozilla.org Team. If you have any questions, ideas for future tests, or if you just want to chat about the future of this page please do not hesitate to get in touch!

Firefox 40 new contributors

Josh Matthews

4 responses

With the release of Firefox 40, we are pleased to welcome the 55 developers who contributed their first code change to Firefox in this release, 49 of whom were brand new volunteers! Please join us in thanking each of these diligent and enthusiastic individuals, and take a look at their contributions:

  • ijdt.editor: 1139429
  • kevin.m.wern: 1148694
  • wrahman0: 1132208, 1150514, 1153877
  • Aaron Graham: 892229
  • Aime Galmi: 1084911, 1132213
  • Ali Movahedi: 1154773
  • Anirudh S: 1134494
  • Anthony Tseng: 1158425
  • Anton Myagkov: 1132558
  • Antonio Ladeia: 1123372
  • Atif Iqbal Ahangar: 1150197
  • Bryan Quigley: 1155943
  • Daniel Miller: 699860
  • Darren Lyons: 1147233
  • David Cooper: 667471
  • Denis Volk: 1095098
  • Dipti Nirmale: 1148095
  • Dmitry: 1154676
  • Dmitry Sagalovskiy: 977586
  • Elbart: 1069979
  • Ethan Wu: 1148268
  • Fabian Furger: 1107941
  • Florian Merz: 1063946
  • Giorgos Logiotatidis: 1155579
  • Gordon Klaus: 1155140, 1155648
  • Ilya: 1125816
  • James Lai: 1150800, 1155956
  • Jose Rios: 1161640, 1161666
  • Julian Descottes: 999568
  • Kai Bittner: 1148167
  • Kartik Somani: 1147398
  • Keita Mimura: 1137234, 1149198
  • Kevin Chen: 1097479
  • Kit Cambridge: 1150683
  • Krishnashish Gogoi: 982852
  • Lee Salzman: 1156536, 1158154
  • Martin Tomes: 1084296, 1160487, 1160489
  • Matt King: 952290, 1140592, 1147027, 1150621
  • Michael[tm] Smith: 1096172
  • Morgan Phillips: 1151834
  • Nazim Can Altinova: 1127234, 1144399
  • Németh László: 318040
  • Patryk:Res: 733679
  • Paul17041993: 979705
  • Ross: 1152454
  • Ryan Hamley: 1150484
  • Ryan Nath: 1158547
  • Shane Tomlinson: 1146904
  • Sheefeni Hauwanga: 1142192
  • Shyam Venkatesh: 1157728
  • Taylor Brown: 1018932
  • TheOneisNEO: 1149872
  • Thibaud Backenstrass : 1157661, 1158122
  • Tomas Flek: 1127139
  • bogas04: 1139026
  • cedric raudin: 1079697, 1115365