Ubuntu Wiki

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad entry: https://features.launchpad.net/distros/ubuntu/+spec/forum-ambassadors

• Packages affected:

Agenda / TODO

• after this meeting the document should still / again be in a clean state. Please keep this always in mind. Let's coordinate the editting. ALWAYS type your name in front of a comment.

agenda for session(s) with pricey,ubuntu_demon and maniac :

1. discuss format of polls/discussion threads (see unresolved issues)
2. CLEANUP and organize implementation in sections (this amount of bullet points is hard to get through)
3. Work on use cases. Define other use cases based on defined tasks. Each task should be respresented by at least one use case. Each use case should be in the tasks list somehow. Making sure everything (goals,tasks,scope..) is in line with the use cases. This goal is missing in the use cases :
4. Integration of software projects that start on the forums into the distribution. (Inviting people into the greater community.)

   • - ubuntu_demon : use case,tasks,scope missing. IMHO it's nice if a development project starts at the forums that the FA assist in bringing it to the rest of the community. TODO Make it reflect in Use cases,Tasks and Scope

5. work on defining reports/reporting and define what sort of email should go to ubuntu-devel / ubuntu-devel-discuss in == design ==
6. CLEANUP the document. Making sure it looks allright in wiki
7. discuss unresolved issues. agenda for public gobby session :
8. go through the document section by section. Discuss all feedback.
9. discuss optimal size of FA team (not size of FA leaders), and possible criteria for joining
10. Work on use cases. Define other use cases based on defined tasks. Each task should be respresented by at least one use case. Each use case should be in the tasks list somehow. Making sure everything (goals,tasks,scope..) is in line with the use cases.
11. CLEANUP the document. Making sure it looks allright in wiki
12. discuss unresolved issues.
13. CLEANUP the document. Making sure it looks allright in wiki

Summary

This document specifies how to improve communication (bugs, ideas, forum users feedback) between the forums and the developers. The idea is to elect Forum Ambassadors and/or have a special forum for this to help to improve communication.

We will create a forum section on ubuntuforums.org where people can request help of the Forum Ambassadors or convey their opinions in a constructive and useful way (see design).

A team of Forum Ambassadors will connect to the developers to facilitate communication. We will use ambassadors to collect ideas, bugs and feedback from users. This team would probably connect to developers via a mailing list, with possibly some irc contact.

This idea originated on the forums. This idea was originally by Aysiu but many people have contributed to this spec. The current forum discussion is here : http://ubuntuforums.org/showthread.php?t=278375

Our intended target is that the Forum Ambassadors become a team like : http://ubuntuforums.org/showthread.php?t=289810 (If this doesn't happen we will become a 3rd party section)

Rationale

Currently there's little communication between the forum users and the developers. The forums can be a great resource for developers that are looking for bugs, testers, or improvement of useablity -- but not in a way that they have to spend too much time browsing the forums. The idea is to bring the forums to the developers with this team, and bring the perceived presence of the developers to the forums.

The proposed Forum Ambassadors Team will improve information flow between the forums and the developers. This information flow will be bi-directional.

It's not practical for the developers to spend much time monitoring the forums. Instead of waiting for developers to come to the forums let's take a more active approach and create this team. The amount of information going from the forum-ambassadors to the developers will be very manageable for the developers.

It also provides a sense of entitlement to the users at Ubuntu Forums. They will feel represented, involved, and perhaps be able to take a larger part in making Ubuntu better. This is definitely good for improving the integration and communication of the forums with the rest of the community.

The users often find it hard to reach the developers, with notices like "Please note developers are not very active here." strung all over the place in bold font. They are told to "file a bug", post to the mailing list, and this may seem daunting in this radically different world. As well as making it easier for the developers to reach the users, the spec tries to make the users able to reach the developers.

Use cases

• Right after Feisty's release there's a big thread on the forums about the breakage of a certain important package. Paul, a Forum Ambassador, contacts the maintainer of this package to let him know about this.
• Karel, a forum user, creates a new thread with some nice workarounds for certain problems. Paul, a Forum Ambassador, discovers that a couple of these problems are unknown to the devs and encourages and assists forum users to report these problems as bugs, including a link to the forum thread in explanation.
• Joe, a forum user, posts with annoyance at how a certain package is not compiled with options to perform something he wants, for example ipod support for a music app. The ambassador informs Joe he will pass on his request by filing a bug to the right package, or gives him the appropriate links and guidance to file the bug himself. This is training up future possible FA's, or teaching people how to get their opinions heard.
• A month before UDS, Traci (a Forum Ambassador) visits Ubuntu Forums, reading through a discussion thread on the development forum. She sees things like suggestions to improve usability, regressions or changes that are disliked, and other complaints and ideas. She filters out the trivia and senseless complaints (about codecs, etc), and compiles her information into a readable report with a few statistics, such as how popular an idea/complaint is. She also encourages people with regressions and complaints to file a bug, and even shows them how if necessary. At the end of an alloted time period, all such reports by FA's are compiled together and sent to the developers.

Scope

• This spec is focused on creating a Forum Ambassadors team which will provide a bi-directional communication interface between the forum users and the Ubuntu developers.

* The only purpose of this project is to gather feedback and input from the users and convey it directly to the developers, and to convey the intentions/thoughts of the developers back to the users. The Ambassadors team's responsibilities will not extend beyond that.

• The focus of this team should *not* be to try to educate every new user. The forums already have a team for that.
• The Forum Ambassadors will also *not* be responsible for resolving inter-user and user/staff grievances. We have a resolution centre for that (Also FC and CC in the future).
• This spec is *not* about improving the documentation flow between forums and wiki.
• This spec is *not* about creating documentation.
• Initially intended for ubuntuforums.org. In the future other Ubuntu forums can possibly learn from us or possibly even join us. For now expanding to other forums is out of scope.

Design

• Forum Ambassadors Team consists of Forum Ambassador Members and Forum Ambassador Leaders. See tasks, criteria for both FA members and FA leaders.
• About FA Leaders:
  • - start with three (3) FA leaders - Defined below are some criteria and tasks for FA leaders

    - the FA leaders are responsible for the FA team (although ultimately the FC see ForumsGovernance is responsible for the ubuntuforums)

• Define Tasks of Forum Ambassador Members, discuss evaluating requests and give examples of things a FA could do:
  • - all FA should try to attend (bi)weekly IRC meetings. The FA irc meetings will be weekly to begin with. - There are different tasks a FA member could do. A FA should just pick and do the task(s) he/she is best at. - there are some tasks (explained with an example) in Use Cases. - help users report bugs - help users write better specs - create/help guide discussions about new or existing feature specifications

    - File bugs (Good bugs) (see [:LoCoTeamsUDSMVSpecs/CommunityBugReporting:CommunityBugReporting]) - Forum Ambassadors can be active in the Forum Ambassadors subforum. In this way they are easy to contact for the forum users. - They could also submit interesting stuff to Ubuntu Weekly News in interesting cases. - combing through the forums for useful feedback/problems/suggestions by users is an optional task. It would be really nice if we had some Forum Ambassadors who would be wanting to do this. It's not required to spend a lot of time combing through the forums though.

  - Forum Ambassadors can start threads to collect feedback on general issues or on a specific issue. These threads will typically be started in our own subforum or in the development section. Some threads (for example about the general direction of the next release) might belong to the Ubuntu Cafe.
  • - writing reports (and emails) to devs / devlists (discuss in implementation). These reports will also be posted in our new forum section. - making sure our reports are well written and try to keep bias low (statistically rich)
• Define Criteria for Forum Ambassador Members:

  • - respect and follow CoC (Code of Conduct : http://www.ubuntu.com/community/conduct) - amount of time dedicating to it *entirely* up to yourself - step down considerately according to CoC (Code of Conduct : http://www.ubuntu.com/community/conduct) - willingness to learn and enthusiasm - shown to be capable and respectful in interacting with community members - Having a sense of what is feasible and what isnt. Having some technical insight into how the Linux/ Ubuntu operating system works is a prerequisite. - If they have the time available, then they should be willing to go to UDS if sponsored. - It is advised that Forum Ambassadors should have a rough idea about what happens on k/x/ed ubuntu-devel , ubuntu-devel-discussion (pick the one you like) - ability to filter requests from users (support request (let staff move it), bug report, feature bug, spec, obvious idea,..)

• Define Tasks of Forum Ambassador Leaders:
  • - can do tasks of regular Forum Ambassadors - guide FA team IRC meetings - making sure reports get written - making sure reports are well written and try to keep bias low (statistically rich) - making sure FA members live up to their criteria - solving inter-team problems if any - communicating with forum staff if needed - holding open (bi-)weekly irc meetings with other FA leaders ("FA leader irc meetings") - holding open (bi-)weekly irc meetings with FA members ("FA team irc meetings")
• Define Criteria of Forum Ambassador Leaders:
  • - the same criteria as for FA members - If they have the time available, then they should be willing to go to UDS if sponsored. - amount of time dedicating to it *entirely* up to yourself. Except for trying hard to be at ALL irc-meetings and responding to emails and pm's.

    - Step down considerately according to CoC (Code of Conduct : http://www.ubuntu.com/community/conduct) - respect and follow LCoC (LeadershipCodeofConduct) - (extra) community experience helps - extra criteria up to the forum admins - appointed by forum admins

• Define stepping down of FA Leaders :
  • - When a FA leader steps down all FA members can volunteer and current FA leaders will pick the one most suitable.
• Define how the subforum should work :
  • - Users can post requests to FA's about something specific (help with reporting a bug,..) - FA members can start discussion threads/polls - Any ubuntuforums member will be able to start threads (irrelevant threads will be closed or moved with a polite message why) - A warning will be placed to ensure that posting guidelines (such as not posting your wishlists, etc) will be followed by all posters. - If the subforum doesn't work we can re-evaluate and change it along the way. - All FA leaders should have the power to close/move threads in this subsection. If that doesn't work maybe all FA members in the future. Discuss with forum admins (part of action plan). (moving won't be possible unless leaders are also mods)
• Goals to achieve
  • Encouraging and assisting forum users in reporting bugs, writing specs and using Launchpad. We will point them to docs, and help them if that doesn't suffice. If there are no docs, ambassadors should help them along by letting someone on the docteam know that the docs are missing.
  • Communicating ideas to developers (gists and zeitgeists (trends))

  • Two way communication. (Bidirectional)

  • Integration of software projects that start on the forums into the distribution. (Inviting people into the greater community.)
• Involve active forum members who know what they are doing to help out with bugs (reporting,triaging). They can become FA and help out users with reporting bugs. (Get the active members to join the Ubuntu project and become FA)
• Getting users to come to us regarding specs in the one month timeslot before the next UDS
• Define types of requests (FA will have to (learn to) recognize which of these it is):

  • - Support request => report to forum staff. Forum staff will move them somewhere else. - Small feature bugs such as "package X needs to be compiled with option Y") => report as wishlist/feature bug to package X. Refer user to documentation, and help them report a bug if needed. - big feature bugs against some package => should probably go upstream. - new ideas possibly suitable for specs => refer to documentation about writing new specs. help when needed (for example suggest a gobby session with interested people). - "obvious ideas" => gently explain to the user that this is an obvious idea and therefore not worth reporting to the developers (they are swimming in bug reports and email already).

• Prioritizing some specs (users might feel something is very important while developers might think it's less important) => A discussion thread with poll is probably the way to go here. It should be made clear that the outcome of the poll doesn't reflect exactly what's going to happen, it will just give the dev's a better understanding of what the users are looking for.

• Define types of other relevant information :
  • - Communicate what users like in other distros

    - "I've stopped using Ubuntu because XXX is, or works better, in Some Other Distro" <-- high priority - Communicating ideas to developers (gists and zeitgeists (trends)) - What specs users feel are important - What users feel the next release should focus on

• define appointment of FA Members and FA Leaders:
  • - people can nominate themselves for FA Leaders and FA Members. - FA Leaders are appointed by Forum Admins. FA Members nominations (and recommendations) are put forward to Forum Admins by FA Leaders and approved by Forum Admins.
• define structure of launchpad team: - moderated team - FA Leaders should be the LP admins. - Explanation of LP admins : In general, LP admins have the power to approve/deny candidates and automatically receive all bugmail from +subscribed bugs.
• define what kind of mail should go to ubuntu-devel:
  • - urgent bugs - reports with compilation of things the FA did (not the discussion about it) - Sarah Hobbs: This depends on how strict the stuff to ubuntu-devel is - i'd imagine very strict, as people dont seem to get what is development stuff and isnt.
• define what kind of mail should go to ubuntu-devel-discuss:
  • - discussion of "reports with compilation of things the FA did" - discussion items such as ideas,specs,... - some bugs ? define what kind of bugs

* define reports:

• - Reports summarize the key issues that people are experiencing at the moment. They also reflect the wishes of the users in regard to what they want for the future of Ubuntu. The reports will often have accompanying statistics to back up and accentuate/prioritize issues and ideas. - Items that are to be included in the report should be prioritized and discussed at the weekly meetings
• meetings: - we have: 1) forums and 2) irc for communication - weekly irc meetings (especially in the beginning)

* Define (bi)weekly IRC team meetings:

• - We will have an agenda somewhere on the wiki. Everything to be discussed should be put on the agenda before the meeting. - The agenda will be prioritized by the FA leaders. The meeting will go according to the agenda. - All FA members and leaders should try to attend for two hours. - Meetings can extend a bit longer than that if there are enough people left to make progress on some issue. - At an FA team meeting without a majority of the leaders present, no decisions such as policy changes will be made. However, civil discussion and progress through the agenda can still be made.
• Define (bi)weekly IRC FA leaders meetings :
  • - Meetings will be short (most issues should be discussed at the normal meetings) - Meetings will mainly be about management issues or structural changes, or changes to policies/the way we work. - These will also have an agenda on the wiki. Everything (as much as possible) to be discussed should be put on the agenda before the meeting. - A majority of FA Leaders are required to be present at an FA Leader meeting, or that meeting will be postponed.

* define conflict handling :

• - scope: any user-FA confict or FA-FA conflict - 1) FA leader tries to solve the conflict
  • 2) if 1 doesn't work out: Resolution Center 3) if 2 doesn't work out: FC (but that won't happen often) 4) if 3 doesn't work out: CC (this probably won't happen at all)

Implementation

action plan / what to do before creating this team

1. work through the agenda today
2. as many gobby sessions as needed to solve most unresolved issues and to work through the agenda.
3. make sure the wiki document is clear and readable
4. ubuntu_demon will blog to planet.ubuntu.com and will send emails to ubuntu-devel and ubuntu-devel-discussion asking for feedback on this document
   • we should try to define what kind of mail we propose to kubuntu/edubuntu/xubuntu/ubuntu -devel and what kind of mail to ubuntu-devel discussion. When we mail to ubuntu-devel for feedback on this spec we should specifically ask for their opinion about this.
   • we have to define the types of reports (see design)
   • CC to jono bacon
5. incorporate dev feedback
6. people should nominate themselves if they want to be FA members. Now that we know what this is based on the last document.
7. people should nominate themselves whether they want to be FA leader.
8. ask the admins to review the document and give their feedback.
9. incorporate admin feedback
10. ask the admins if they want to make this Forum Ambassadors team official. Ask them for a forum section and if official ask them to create the forums team. Ask them to appoint 3 leaders. (There will probably always be 3 FA leaders.)

11. create moderated launchpad team. Hobbsee already created one : https://launchpad.net/people/ubuntu-forum-ambassadors/

    • This LP team won't be used until points 1-9 are done.
12. We have to make sure we can post to ubuntu-devel, edubuntu-devel, kubuntu-devel and xubuntu-devel (the new team will ask Jono Bacon).
    • ubuntu_demon : AFAIK only ubuntu-devel is moderated currently by Jono Bacon.
13. request official irc channel?
14. This document is only one possible implementation of a very good idea. We have worked hard to make it all feasible and useful before it is put into practice. The final implementation is up to the admins and Forum Ambassador Leaders (appointed by the admins).
15. The FA will mostly use ubuntu-devel and ubuntu-devel-discuss (? to be confirmed) when communicating with developers. The FA can't flood ubuntu-devel. The FA will have to make sure the email they send is really really useful. In the beginning they will discuss with eachother before sending an email to ubuntu-devel / ubuntu-devel-discuss. The FA will slowly learn how to communicate best with the devs.
16. We have defined some criteria that have to (at least) be present in Forum Ambassadors and Forum Ambassador Leaders. The admins should appoint three volunteers to be Forum Ambassador Leaders. Forum users can (privately or publicly) volunteer themselves to become Forum Ambassador. Forum Ambassador Team Leaders can suggest new candidate FA members to the forum admins. The final decision for appointing new FA members is up to the forum admins.
17. Create special forum section dedicated to make it easy for forum users to contact Forum Ambassadors. Communication between forum users and FA should primarily happen in this forum section.
18. The FA team should start small (about 5-10 FA members, depending on the amount of capable volunteers and 3 FA leaders) and slowly increase in size. The actual size of this team will always be moderated and decided by the FA Leaders.
19. Create document: HOWTO be an ambassador
20. FA don't need specific tasks. forum moderators don't have specific tasks and this works out nicely. Let's try to use the same dynamic approach for FA also.

21. We need, but won't produce as this is out of scope, nice documentation : "How to file a good bug report". This ties in with this spec about documentation to report bugs : https://features.launchpad.net/distros/ubuntu/+spec/community-bug-reporting

22. Forum Staff and Forum Ambassadors are two separate things. But it's possible for a forum user to be both. Some Forum Ambassadors might make good Forum Staff. Some Forum Staff might make good Forum Ambassadors.
23. It's important that potential Forum ambassadors know that they don't have to be developers to talk on a developer level - it's not like the developers are unapproachable, nor that they need to be talked to in a weird language - they do understand day to day English. I suspect there are a lot of people who think "I cant do this, I'm not skilled enough to." If you have a reasonable knowledge of what is feasible and isn't, we need you!
24. Forum Ambassadors should try to filter out obvious and useless ideas. FA Leaders should try to keep the number of emails to ubuntu-devel low since developers are already drowning in bugreports and email.
25. It's also important that we don't nag too much about obvious stuff. This takes too much time of the developers. Explain why it's obvious in a gentle and decent way.(example obvious and useless idea : backporting a feisty kernel to dapper)
26. We should try to have at least one Forum Ambassador at every (Kubuntu/Community) council meeting and report there (briefly). (idea by Jonathan Ridell)

27. Priorities poll during the 1 month timeslot before UDS to help define the direction of the next Ubuntu Release. For example : [bling,multimedia,server hardware support, desktop hardware support,laptop hardware support,security&stability,easier/better package management, bleeding edge stuff]

28. Henrik Nilsen Omma https://wiki.ubuntu.com/HenrikOmma (heno on irc) :

    • Volunteers to be a point of contact. Can help us a little bit for example with evaluating some reports before we send them. Can give us a bit of guidance.
    • A suggestion from him : Maybe the FA team can encourage testing of cd images. This can help the devs a lot.
    • ubuntu_demon will contact him when wiki the is cleaned up.
    • ubuntu_demon and Henrik will keep in touch

Evaluation

• Forum Ambassadors and Ubuntu developers should know about each others existence and can find each other on launchpad
• Forum Ambassadors should know what's going on in the world of Ubuntu in general (devel mailinglists, developer forum section, FA forum section included)
• posts in ubuntu-devel, kubuntu-devel,xubuntu-devel,edubuntu-devel, ubuntu-motu and the new FA forum section are readable for everyone
• report to Ubuntu Weekly and ubuntu-devel on an irregular basis (maybe regular later)

Unresolved issues

• We shouldn't give credit to users who "found" a bug; if they don't submit it, they don't get credit. We should have an LP user called "FA Bug Reporter" who gets credit for these. The details for this user will only be given out to FA members, so that only they can file bugs/specs/whatever with this account. This also helps make sure karma is distributed evenly, not to anyone in particular, and nobody complains.
  • - ubuntudemon : no accountabillity. Moving to unresolved issues. This won't block the creation of the FA team.
• Maybe FA should automatically be subscribed to new specs at the next UDS ?
  • - ubuntudemon : there are lots of specs registered to the new UDS if you automatically get subscribed to all of them your email will be spammed. I'm against doing this on default.
• There will be regular polls (discussion) threads about specific subjects organized by the Forum Ambassadors. These polls can be about all kinds of relevant things such as : bugs, regressions, feature specifications, (small) feature requests and so on.
• Outline for the format of creating poll threads in the FA Subforum:
  • First, a variety of free-thought threads will be created, according to logical categories
    • Categories: Bug Reports, Regressions, Feature Requests, and Ideas (this last section would contain ideas that will help Ubuntu become better...not necessarily just Feature Requests; and this would need to be made clear as crystal) -ubuntudemon : what's an idea if it's not a feature request or spec ? - it could be a spec.
  • Then, after a short period of allowing free-thought and the development of ideas, these threads will be closed. The best, most feasible ideas will then be selected out of them.
    • - ubuntudemon : I don't see the need of closing them .. they will die out eventually - some eople like reviving old threads. just to keep things organized. its not a poltical action, just one in the interest of efficiency.
      • we can close them when someone revives an old thread or when it becomes a problem. IMHO we shouldn't close a thread when it's not necessary
    • In groups of 4-6 items, these "best" ideas will be put up as polls and the Ubuntu Forums community will vote on them. Thus, they will selectively be narrowed down until only a handful are left (this only applies partly to the Bug Report thread...it'll be a way of finding the most serious bugs, but all confirmed bugs will be reported)
  • The ideas that survived the polling will be compiled into a final report. (we need to figure out the time constraints of this and how long we will have to do the polls/submit the results and give the devs enough time to implement some of it)
  • To effectively keep track of threads, an FA can volunteer to monitor a thread so that all ideas can be kept track of.
    • ubuntudemon : I removed "assigned"

  • TobySmithe: After every meeting, these threads should be cleaned and reopened. However, this would depend greatly on the amount of people willing to do this, and the amount of time available.

Brain Dump

• For the below, read up on line 247 in the Implementation section of this document; which is a good compromise on all the points made below.
• sicofante: Tag threads from any subforum and create a virtual subforum that contains issues relevant to developers. This is the whole idea: The subforum would be created as a virtual subforum via the use of tags. It will be visible in the main forums page by creating a direct link to a tag search and by using the forumdisplay option for tags searches in [WWW] Zoints vBulletin add-on. Instead of having a dedicated "real" subforum, this approach has the following advantages:
  • - sicofante:No crossposting needed. The OP might want to keep the thread as it was originally intended (a help demand, a complaint, a request, whatever) and just tag it so the ambassadors can use it to show the issue to the devs.
    • ubuntu_demon : so the FA might have to go through a big thread to find the actual request. IMHO this is a disadvantage.
    - sicofante:The OP might not intend its post to be used by ambassadors but the mod still believe it would be useful, so the thread could go on "as is" and still serve the purpose of showing to the devs a particular point. - sicofante:Where the thread originally started will bring useful information to devs, mods and ambassadors. For instance, threads tagged from the beta testing forums are quite different from those coming from "absolute beginners". - sicofante:Ambassadors might "de-tag" some threads to prevent abuse. This might help the ambassadors getting a cleaner look at what they have to say to the devs. - ubuntu_demon : IMHO users should make the concious effort to go to the FA. This will make the amount of work a FA has to do manageable and it will mean that only people who actually want help with their spec/bugreport come to us. The FA is not for helping with support requests. - ubuntu_demon : forum staff can move threads to the FA forum section when they feel this is useful/necessary - sicofante: asking users for that effort is OK, but that will leave out issues that users simply complaint about in other forums. - ubuntu_demon : that's where polls come in. Also FA can start discussion threads in the FA forum or developer subforum to get valuable input.

    - PriceChild: The tags search doesnt' work like a normal forum, newer posts don't bump topics to the top. We'd have to try and keep it as clean as possible once the issue is dealt with. - I would prefer a separate forum with new discussion threads and simply a link to the original post because of this.

== Future work ==

• Forum ambassadors could tag threads with a specific code (i.e. "FA") so that they could then search through new ideas using the tag search of (specifically the English ubuntuforums.org). This way; as tag searches show the newest thread at the top of the list (and new posts to old threads don't bring them to the top as in the normal forum view), FAs can easily look for bug reports, ideas to report when they are able. There could be a multitude of tags, so that FAs can distinguish between bug threads and spec threads, or, if that is deemed too complicated, just the one. Although it may be seen as an advantage for users to go to the forum ambassadors, this would ease up on work for the users, who may have good reports that otherwise wouldn't be noticed. This feature is just an alternative methods to make things easier, and does not absolutely HAVE to be used. We will still have users posting to the forums, this is just a good way of keeping track of interesting threads. This idea is a more feasible version of the one proposed in the Brain Dump section of this document
  • Expanding to other forums

archived commments

Archived comments: [wiki:ForumAmbassadors/Talk Talk page]

Comments

• I think this is a great Idea. From a forums perspective at least the English one it will be really simple to allow this to be setup as a team with the option of users to request to join etc. I would like to see this implemented for sure. Ryan Troy
• I think its a great idea to really well thought out. if its implemented right will work out great. zenrox

CategorySpec