ForumAmbassadors

Differences between revisions 31 and 68 (spanning 37 versions)
⇤ ← Revision 31 as of 2006-11-10 01:59:42 →
Size: 17757
Editor: 207
Comment:
← Revision 68 as of 2008-08-06 17:01:37 → ⇥
Size: 34889
Editor: localhost
Comment:
Deletions are marked like this. Additions are marked like this.
Line 1: Line 1:
||<tablestyle="float:right; font-size: 0.9em; width:40%; background:#F1F1ED; margin: 0 0 1em 1em;" style="padding:0.5em;"><<TableOfContents(3)>>||
Line 6: Line 8:
 * '''Packages affected''':
 
== BoF agenda and discussion ==

 * Currently this spec is in drafting.
 * There will be another BOF about this on Thursday or Friday. Interested forum members should try to attend.
 * Many of the current comments are things that should actually be bullets, as they're valid points and ideas, not just comments. Before the next drafting, this should be amended. I'll work on it, so help me :)
 
 * Asking good questions
  - PriceChild: There's a good thread on the forums, i believe by aysiu. -Is this part of our implementation?
  - UbuntuDemon : I think we should make at least three documents : 1) HOWTO Forum Ambassador .. howto help, what to do and stuff 2) some addon to jono's spec on forums specific stuff (for example things that forum userstend to do wrong .. we should communicate it back to jono when this happens ofcourse.3) when to approach a forum ambassador. Developers made it clear to me that they like the idea but they wouldn't like to see us spamming them with every idea some user has. Some are really obvious .. others are more suitable to post as a feature bug ... we can help users with this ofcourse. We should educate users a little bit on what type of stuff is interesting for developers.
    -ManiacMusician : Of course we wouldn't spam them. It's our job to filter out the feedback we're investigating. It's okay to educate users but the fact is, most of them won't read. And, I thought the idea was for them to write what they wanted the developers to know.
    - UbuntuDemon : All I wanted to say was we should make it clear what kind of things developers are interested in so 1) we can do a bit of pre-filtering and 2) users become less dissapointed if we don't act on their wishes
   - UbuntuDemon : IMHO we can put it under future work. under a bullet called documentation
    - UbuntuDemon : what do you think ?
     -ManiacMusician : It's a good idea. Definitely too much work for us right now though, so we do need to put it innn the future work section like you said
       - UbuntuDemon : No IMHO it's part of implementation. It's not that we can't start without it though :)
      - PriceChild : I'm thinking it'd be better to educate what is NOT wanted by the devs.
        - UbuntuDemon : that might be easier :). nice idea. But we should also use Use Cases to show what might be interesting for devs.
     - UbuntuDemon :IMHO we should ask Aysiu to help us write the HOWTO Forum Ambassador. IMHO we should also invite him to the team.
      - ManiacMusician : He has already publicly declined to be on the team. But I'm sure he would be willing to help write the HOWTO.
      -UbuntuDemon : he publicly declined but the spec has progressed and is somewhat different from his initial idea
       - ManiacMusician : Well the reason for his declination was that he said he wouldn't be able to be impartial like Ambassadors should be and that it wasa too huge a commitment
       - UbuntuDemon :IMHO everyone should decide how much time to spend on this themselves. We should make this clear in the HOWTO.
         - UbuntuDemon : we can slowly grow the FA team. Lots of people dedicating a bit of time is a lot of time together.
  -UbuntuDemon :let's tag these comments and move them to discussion. Okay ?
 
     == Agenda / TODO ==
 * See the actionplan in implementation for more TODO.
Line 38: Line 15:
This idea originated on the forums. It was originally by Aysiu but many people have contributed. The current discussion is here :
the forum thread : http://ubuntuforums.org/showthread.php?p=1708930

Forum Ambassadors might become a team like :		 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, concise 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 UWN, mailing lists or irc.

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 :
Line 43: Line 23:

 * Summary - Subforum on the forums where people have opinions and ideas. Make a team that connects to the developers to facilitate communication.
 * Use ambassadors to collect ideas,bugs and feedback from users.
 
TODO: improve the spec and make it more clear		 (If this doesn't happen we will become a 3rd party section)
Line 51: Line 27:
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. 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.
Line 54: Line 30:

It's not practical for the developers to spend much time monitoring the forums. The amount selected by the ambassadors team for the developers should be a lot easier to handle than the huge amount of posts on the forums. Instead of waiting for developers to come to the forums let's take a more active approach and create this team.

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. True this is definetely good for improving the integration and communication of the forums with the rest of the community.		   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.
Line 61: Line 39:
 * 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.

 * 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.

 * Traci, a Forums Ambassador, creates a thread asking for suggestions regarding ideas for improved usability, new things that don't ring very true with the users. Traci summarizes the discussion, filters out trivia and senseless complaints, and forwards the good ideas and suggestions to the developers in the following way : first create specs for these ideas, secondly send an e-mail to ubuntu-devel for discussion and thirdly attend the next UDS to discuss these specs.		  * 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, helps the users to report the bug and 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 gives him the appropriate links and guidance to file the bug in the right package for the maintainer to take on board.

 * A month before UDS, Seb (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.
 
 * Traci, a Forum Ambassador, notices there's a new forum subsection for a new project Blaat. Traci contacts the people behind Blaat and asks them whether they have communicated with the developers about this Blaat. Traci encourages the people behind Blaat to write to ubuntu-devel(-discussion) to get communications with (and feedback from) the developers going. Traci also encourages the people behind Blaat to write to ubuntu-motu or come to #ubuntu-motu if they want their project to become an official (universe) ubuntu package.

 * Herd 3 of Feisty Fawn is just released. Pieter, a forum ambassador, starts a sticky to notify people to help testing and links to the ISO testing project subforum http://www.ubuntuforums.org/forumdisplay.php?f=201. When Pieter talks to people who are testing Feisty, he encourages them to do the testing more offcially if they have the time for it. This involves being active in reporting bugs and discussing development of the upcoming release.
 
 * Henri, a forum user upgraded to feisty because he thought that feisty has v0.1.4 of alsa and alsa v0.1.3 doesn't support his sound card he says that his card is very popular. and it will be a bad thing if feisty will not support it. Patrick a Forum Ambassador tells Henri that it is unwise to run feisty while it is not released as your main operating system. Then helps Henri to report a (feature) bug (maybe also on alsa's bugtracker).
Line 71: Line 55:
This spec is focused on creating a Forum Ambassadors team which will provide a bi-directional communication interface between the forum users and the developers.

The focus of this team should not be to try to educate every new user, although the team would assist communication between forums users and developers.

 * 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 focused on creating a Forum Ambassadors team which will provide a bi-directional communication interface between the forum users and the Ubuntu developers.
Line 78: Line 58:
    * 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.
Line 81: Line 71:
 * Goals to achieve
  * To encourage and assist forum users in bug reporting, wiki usage and other community tools.
  * Communicating ideas to developers (gists and zeitgeists) 		=== structure of the team ===
 * Forum Ambassadors Team consists of three Forum Ambassador Members and Forum Ambassador Leaders. See tasks, criteria for both FA members and FA leaders.
  * 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.
  * 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.
 
 * 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.
  
 * 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 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.

=== comparison with bugsquad ===
 * see point 15 of the action plan (in implementation)

=== tasks,criteria and responsibilities of the Forum Ambassador team Members ===

 * FA don't need dedicated 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.
  
==== Tasks of Forum Ambassador Members ====
 * 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 by giving appropriate guidance and links to documentation. (''see'' [[LoCoTeamsUDSMVSpecs/CommunityBugReporting|CommunityBugReporting]])
 * help users write better specs
 * create/help guide discussions about new or existing feature specifications
 * 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)
 * encouraging (forum) people with new (programming) projects to write to ubuntu-devel(-discussion) to get input and feedback. And encouraging them to write to ubuntu-motu or go to #ubuntu-motu if they want their project to become an official (universe) package).
 * encourage (forum) users to help test cd-images. We want to involve more people in the image testing so we can eventually get broader testing on more hardware and conduct a wider range of tests. http://www.ubuntuforums.org/forumdisplay.php?f=201
  
==== 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,..)

=== tasks,criteria and responsibilities of the Forum Ambassador team Leaders ===
 
==== 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.
   
=== the new Forum Ambassadors subforum ===

 * 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.
   
 * 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)
   
==== polls/discussion threads in forum section ====

 * 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]
 
 * 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.

 * Forum Ambassadors can create quick polls/discussion threads
  * Forum Ambassadors can also do it a bit more professional. For example in the following way :
  * 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)
   * Then, after a short period of allowing free-thought and the development of ideas, the best, most feasible ideas will be selected.(if needed and obsolete threads can be closed and/or the original post can be modified)
    * 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.

=== 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))
Line 85: Line 182:
  * Integration of projects that start on the forums into the distribution. (Inviting people into the greater community.)
  * Involve other active members of the forums that don't yet contribute to the organization. (Get the active members to join the project)
  * Recognition of forums contributions


 * Things ambassadors will be doing
  * Some people are comfortable collecting information. (Collector)
  * Some people are comfortable diseminating information. (Disseminators)
  * Triaging people and volunteers (being in touch with the interests of users)
  * File bugs (Good bugs, not just follow either, is it a feature or a bug? They need to be able to contact people who are willing to contribute.) (''see'' [:LoCoTeamsUDSMVSpecs/CommunityBugReporting:CommunityBugReporting])
  * Report on the team's work and achievements over a timeframe... monthly?
  * Forum Ambassadors should be active mainly in the Forum Ambassadors subforum. In this way most of what they do is transparent to the forum users. They could also submit interesting stuff to Ubuntu Weekly News in interesting cases. When we grow bigger we might report in a more official manner to the Forums Council.
  
  
  		  * 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.
  
  
=== information we are interested in ===
 * 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

=== communcation with devs ===
 
 * 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.

 * 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!
 * 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.
 * 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)
 * We should try to have at least one Forum Ambassador at every (Kubuntu/Community) council meeting and report there (briefly). (idea by Jonathan Ridell)

 * define what kind of mail should go to ubuntu-devel:
  * we should let ubuntu-devel know of urgent bugs, but we're not the ones that file the bug; point them to whoever did file it on LP and relevant threads if available
  * 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,...

==== 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
 
=== bug reporting ===
 * We feel that in line with the "howto file a bug" doc, the original discoverer of a bug should be encouraged to take the easy steps required to file the bug themself. If the user in question does not file a bug, another user in the thread able to recreate the bug and who is still active should then be encouraged to file it. If neither the original discoverer or someone who is able to reproduce the bug reports the bug shouldn't be filed as there will be no source of further information.

=== intra-FA-team communication ===
 * 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.

=== conflict handling ===
 * 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)
 
Line 101: Line 254:
   * We would like to jumpstart this new Forum Ambassadors team with maniacmusician,pricechild,Sarah Hobbs,Aysiu and UbuntuDemon if all these people are willing to participate (we should ask them). We have to ask the forum admins for approval of this ofcourse.
 * Everyone who puts himself forward and meets the criteria will be considered as a candidate to be member of the Forum Ambassadors Team.
  - UbuntuDemon : we have to write out the criteria like : following the CoC, being an active member of the forums and having showed capable of respectful behaviour, having some technical insight and be willing to learn
 - everybody happy with this ? let's define the criteria later--yup, good idea. thats why i marked it as a comment for now

 * Create Launchpad team for Ambassadors
 * Define types of relevant information : bugs, specs and ideas, priority of specs as felt by the forum users.
 * Document HOWTO be an ambassador
 * create ambassador team leaders
 * set criteria that we want to see from members
 * 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
 * Submit submittor to bug report.
 * Create special forum section dedicated to make it easy for forum users to contact Forum Ambassadors
 * Two way street. Developers and forum users.
 * Forum Staff and Forum Ambassadors are two seperate 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.
 * Set of criteria of contributions.
 * It's important that people 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!
 * It's also important that we don't nagg too much about obvious stuff. This takes too much time of the developers.
 * We have to make sure we can post to ubuntu-devel , edubuntu-devel and kubuntu-devel.
         
=== about this document ===

 * 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).
 
 * 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.

=== 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 / ubuntu-devel-discussion asking for feedback on this document.
  * We should specifically ask for feedback on the "communication with devs" part of design.
  * CC to jono bacon
 5. incorporate dev feedback in small meeting
 6. ask the admins or FC to review the document and give their feedback.
 7. incorporate admin/FC feedback (maybe in small meeting)
 8. people should nominate themselves if they want to be FA members / leaders.
 9. 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.)
 10. The FA Leaders will propose candidates to become FA Members, and the admins will either approve or deny this request.
 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-10 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. (#ubuntuforums-ambassadors sounds nice)
 14. Create document: HOWTO be an ambassador
 15. talk with bugsquad. bugsquad is in a way a similar team. We can learn from them. write comparison with bugsquad. Communication with bugsquad is useful.

=== discussion of dev feedback ===

 * Start with a tight scope (helping with bugs,reporting important bugs to UWN) and slowly broaden the scope to the other tasks we have defined.

 * In the future we envision a lot of different tasks for forum-ambassadors such as helping users report bugs, helping users write specs, guide discussions about new specs and much more. We hope forum-ambassador volunteers will choose tasks based on skills,interest and time. We think it's a good idea to use UWN to report things like interesting threads to.

 * we want to start soon. we don't want to spend too much time on the document anymore. we'll learn as we go along.

 * It's not entirely clear to us what kind of tasks you envision the launchpad ambassadors to do. There's probably some overlap between these projects. Maybe both project can learn from eachother and cooperate on some stuff. As and when the launchpad ambassadors begin working the operations of the forum ambassadors can be adjusted easily.
 
=== Forum Council Feedback ===
The following link contains a summary of the meeting where the forum ambassadors spec was presented to the FC.
They have agreed to recognise us and provide any assistance we require.

https://wiki.ubuntu.com/MeetingLogs/ForumCouncil/2007Feb13

=== nominate yourself for FA member/leader thread ===
first post :

About Forum Ambassadors :

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, concise 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 UWN, mailing lists or 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 : [WWW] http://ubuntuforums.org/showthread.php?t=278375

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

This news :

We are happy to inform you that we are currently in a phase of the forum-ambassadors project where it makes sense to investigate who wants to become Forum Ambassador members / leaders.

We will probably start with a tight scope (helping with bugs,reporting important bugs to UWN) and slowly broaden the scope to the other tasks we have defined.

If you are considering to join the Forum Ambassador team you should read the wiki : https://wiki.ubuntu.com/ForumAmbassadors. If you think you make the requirements you should introduce yourself and tell us what kind of tasks are suitable for you. You can find a list of possible tasks for Forum Ambassadors members on the wiki. We need volunteers to make this work :).

We will soon ask the admins to make the new forum-ambassadors project an official ubuntuforums project and team.

 
=== documentation & tools ===

 * 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
 * We will create a document: HOWTO be a forum ambassador
 * packages.ubuntu.com and packages.debian.com
 * Merge-o-Matic http://merges.ubuntu.com
 * #ubuntu-bugs and Ubuntu Bugsquad https://launchpad.net/~bugsquad
 
=== some developers who have helped us and/or who have volunteered to give us some guidance ===
 * ubuntu_demon spoke to some devs in person during UDS Mountain View about this idea. This input was very valuable.
 * feedback of Sarah Hobbs (Hobbsee) has helped us during the creation of this document.
 * Henrik Nilsen Omma https://wiki.ubuntu.com/HenrikOmma (heno on irc) :
  * Henrik volunteers to be a point of contact. Henrik can help us a little bit for example with evaluating some reports before we send them. He can give us a bit of guidance.
  * A suggestion from Henrik : Maybe the FA team can encourage testing of cd images. This can help the devs a lot.
  * ubuntu_demon will contact Henrik when wiki the is cleaned up.
  * ubuntu_demon and Henrik will keep in touch
Line 125: Line 342:
 * ambassadors + dev teams should know each other
 * ambassadors should know what's going on (#ubuntu-devel, ubuntu-devel, mailinglist, developer forum section)		  * 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 by Forum Ambassadors 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)
Line 129: Line 349:

 * It's not possible to create a bug in the name of someone else.
  ''-MikeBasinger But you can subsubscribe other people to the bug''
   ''- Hobbsee : Only if they have a LP account''
     ''-ManiacMusician : I think that if they're not going to file their own bugs, they might not need (or deserve) to take the credit for it. So, does it really matter whose name the bug is created in?''
      ''- Hobbsee : No, karma doesnt really apply to forum people anyway*de''
 * Need feedback from developers on what they would like to see in this spec.
  ''- Hobbsee : Devs probably need to wait for the forum half to get more organised before we can say much about it. However, we can try to help point out what is feasible and what isn't''
   ''-ManiacMusician : I think everything in this spec is pretty reasonable; especially since most of the work is not being done by the developers. They basically just need to agree that they want to hear users' opinions. On the forums themselves, it'll be the job of the ambassadors to weed out the unfeasible. ''
    "-Hobbsee - Yes, and figure out how the communication will happen. -Hobbsee''
     "-ManiacMusician : I think an Ambassadors mailing list would be reasonable. People who care or are integral can subscribe, and the rest don't have to.''
 * need feedback from Forum users
 * Centralized team leader or should each team member have a point of contact.
 * I, UbuntuDemon, have been doing some talking with some devs and stuff. I'm going to do some informal talking about this Forum Ambassadors stuff to developers. I have been getting good feedback.

 * Central point of contact? Or distributed by team? How do you get decent coverage?
   ''-ManiacMusician: I feel it should be a combination. A central team that coordinates the movements of all the teams, and then separate teams of 3 to 5 people that cover special areas or branch out in some way''
 * Existing staff too busy to be ambassadors? ''-ManiacMusician : For the most part, yes''

 * no leaders ? one or two leaders ? (depends on the role of the FA leaders)
 * we need to clarify what exactly the FA leader(s) should do
 * need to clarify appointment process. Maybe something like : people can nominate themselves and be appointed by FC.

 * The issue of electing forum ambassadors is still open. We can't accept every volunteer...it's a demanding job, and we can't afford to have people that may quit after a little while of doing it. it's a team-based effort. We have to formulate a way to accept members without being too elitist
  ''- PriceChild : Who has final say on Ambassadors? - Forums Staff? Admins or FC?''
    ''- Hobbsee : Forum council, i guess. Which will mostly be the forums staff, i thought?''
     ''- PriceChild : Nope, starts with 3 admins, will change. How about the entire staff team with final decision by FC?''
     '' - Hobbsee : Sounds sane to me. That's what we do for kubuntu, but it's not my decision"
       ''-ManiacMusician : Not sure how I feel about external influences in this. I was kind of hoping to keep it inside the forums, because that's where the community is...those are the people that will have to be represented and they'll probably want to know or have a say in what's going on. What would the FC know about users on the forum?
        ''- PriceChild: Forums Staff & FC are all in forums. FC HAVE to be a good member of the forums to be selected. i.e. admins to start with, maybe with the most experienced staff.''
        ''- Hobbsee : Seeing as the FC is made up of all/mostly staff - a lot. No one's out to get anyone else.''
         ''-ManiacMusician : Didn't mean to imply that. Just wondering about the what the reaction will be at the forums.''
          ''- Hobbsee : Presumably it'll be made very clear on the forums who the members of the FC are, and so users can easily see that they're well known forum people.''
 
== Brain Dump ==

 * expand to other forums
 * offtopic : all Ubuntu forums linking to eachother (for example forums for different languages)
 * bi-directional
 * communicate / relay ideas : gisting + zeitgeist??)
 * prioritization of specs,etc
 * What do other distros do regarding ambassadors ?
 * Communicate what users like in other distros
   ''-ManiacMusician : this is a priority''
 * file + follow up good bugs / inital triage / judgement calls
 * integration of code into community + core distro/repos
 * invite forum members into Ubuntu project + recognition of forums contributions
 * use launchpad
 * "I've stopped using Ubuntu because XXX is, or works better, in Some Other Distro" <-- high priority
    * There are no unresolved issues. There's stuff to do and discuss though. See Agenda / TODO and action plan in implementation.
 
Line 180: Line 353:
  * Integration of other forums (all the LoCo forums and other languages). How do we get their feedback integrated? (Tough, this will be another spec).
  * Ambassadors from other forums? 		 * Expanding to other Ubuntu forums
 * 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

== archived commments ==

''Archived comments: [[ForumAmbassadors/Talk|Talk page]]''
Line 185: Line 362:

''Archived comments: [wiki:Self:ForumAmbassadors/Talk Talk page]''
Line 190: Line 364:

    * Bug Reporting:
  * "Someone on the forums find a bug, want a way to quickly get that information to developers."
    Mako: It would be nice if people who represent others know how to file good detailed bug reports.
  * Someone needs to collect information from the forums, it's unreasonable to expect all users to register with launchpad, etc. etc.
  * Very often forum users post their opinions (requests, problems, desires, etc.) in the "Ubuntu Development" section of the forum thinking that the developers would see their posts there.
   * quote from http://ubuntuforums.org/forumdisplay.php?f=179
    "Please note developers are not very active here. If you wish to file a bug report please do so here." (here is link to https://launchpad.net/distros/ubuntu/+filebug
  * Have you considered how the sister projects (ie. Xubuntu, Kubuntu, and Edubuntu) fit into the mix? -- CodySomerville <<DateTime(2007-01-08T01:11:46Z)>>
  * This will be for Ubuntu and all (big) sister projects. We hope to get forum ambassador members running all (big) sister projects. Most (but not all) forum users use either Ubuntu or Kubuntu. Sarah Hobbsee of Kubuntu helped us with brainstorming. I spoke briefly to Jonathan Riddell of Kubuntu who suggested attending Kubuntu Council meetings. I attended UDS-mtv personally and we got some good initial feedback. Since then the document has evolved and we need some more (dev) feedback. -- UbuntuDemon
 * Good spec, and an important project. However, SUGGESTION - this project is extremely people heavy, I think you would benefit better by allowing forum users to do a certain amount of direct contribution. This could be easily achieved by '''mirroring more mailing lists'''. Personally, I think its vital that we work to reduce overhead by ensuring that mailing lists are read by forum users in the format that they are used to, and mailing list subscribers can read forum users comments in the format that they are used to. This would automatically help to keep forum users up to date and allow them to contribute directly, for example to ubuntu-devel-discuss. At the same time, the Forum Ambassadors team could work to complement this. --[[mdke]]
 

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.

Agenda / TODO

  • See the actionplan in implementation for more TODO.

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, concise 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 UWN, mailing lists or irc.

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, helps the users to report the bug and 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 gives him the appropriate links and guidance to file the bug in the right package for the maintainer to take on board.
  • A month before UDS, Seb (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.
  • Traci, a Forum Ambassador, notices there's a new forum subsection for a new project Blaat. Traci contacts the people behind Blaat and asks them whether they have communicated with the developers about this Blaat. Traci encourages the people behind Blaat to write to ubuntu-devel(-discussion) to get communications with (and feedback from) the developers going. Traci also encourages the people behind Blaat to write to ubuntu-motu or come to #ubuntu-motu if they want their project to become an official (universe) ubuntu package.

  • Herd 3 of Feisty Fawn is just released. Pieter, a forum ambassador, starts a sticky to notify people to help testing and links to the ISO testing project subforum http://www.ubuntuforums.org/forumdisplay.php?f=201. When Pieter talks to people who are testing Feisty, he encourages them to do the testing more offcially if they have the time for it. This involves being active in reporting bugs and discussing development of the upcoming release.

  • Henri, a forum user upgraded to feisty because he thought that feisty has v0.1.4 of alsa and alsa v0.1.3 doesn't support his sound card he says that his card is very popular. and it will be a bad thing if feisty will not support it. Patrick a Forum Ambassador tells Henri that it is unwise to run feisty while it is not released as your main operating system. Then helps Henri to report a (feature) bug (maybe also on alsa's bugtracker).

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

structure of the team

  • Forum Ambassadors Team consists of three Forum Ambassador Members and Forum Ambassador Leaders. See tasks, criteria for both FA members and FA leaders.
    • 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.
    • 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.
  • 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.
  • 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 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.

comparison with bugsquad

  • see point 15 of the action plan (in implementation)

tasks,criteria and responsibilities of the Forum Ambassador team Members

  • FA don't need dedicated 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.

Tasks of Forum Ambassador Members

  • 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 by giving appropriate guidance and links to documentation. (see CommunityBugReporting)

  • help users write better specs
  • create/help guide discussions about new or existing feature specifications
  • 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)
  • encouraging (forum) people with new (programming) projects to write to ubuntu-devel(-discussion) to get input and feedback. And encouraging them to write to ubuntu-motu or go to #ubuntu-motu if they want their project to become an official (universe) package).

  • encourage (forum) users to help test cd-images. We want to involve more people in the image testing so we can eventually get broader testing on more hardware and conduct a wider range of tests. http://www.ubuntuforums.org/forumdisplay.php?f=201

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,..)

tasks,criteria and responsibilities of the Forum Ambassador team Leaders

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.

the new Forum Ambassadors subforum

  • 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.
  • 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)

polls/discussion threads in forum section

  • 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]

  • 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.
  • Forum Ambassadors can create quick polls/discussion threads
    • Forum Ambassadors can also do it a bit more professional. For example in the following way :
    • 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)
      • Then, after a short period of allowing free-thought and the development of ideas, the best, most feasible ideas will be selected.(if needed and obsolete threads can be closed and/or the original post can be modified)
        • 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.

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.

information we are interested in

  • 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

communcation with devs

  • 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.
  • 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!
  • 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.
  • 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)
  • We should try to have at least one Forum Ambassador at every (Kubuntu/Community) council meeting and report there (briefly). (idea by Jonathan Ridell)
  • define what kind of mail should go to ubuntu-devel:
    • we should let ubuntu-devel know of urgent bugs, but we're not the ones that file the bug; point them to whoever did file it on LP and relevant threads if available
    • 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,...

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

bug reporting

  • We feel that in line with the "howto file a bug" doc, the original discoverer of a bug should be encouraged to take the easy steps required to file the bug themself. If the user in question does not file a bug, another user in the thread able to recreate the bug and who is still active should then be encouraged to file it. If neither the original discoverer or someone who is able to reproduce the bug reports the bug shouldn't be filed as there will be no source of further information.

intra-FA-team communication

  • 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.

conflict handling

  • 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

about this document

  • 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).
  • 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.

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 / ubuntu-devel-discussion asking for feedback on this document.
    • We should specifically ask for feedback on the "communication with devs" part of design.
    • CC to jono bacon
  5. incorporate dev feedback in small meeting
  6. ask the admins or FC to review the document and give their feedback.
  7. incorporate admin/FC feedback (maybe in small meeting)
  8. people should nominate themselves if they want to be FA members / leaders.
  9. 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.)
  10. The FA Leaders will propose candidates to become FA Members, and the admins will either approve or deny this request.

  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-10 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. (#ubuntuforums-ambassadors sounds nice)
  14. Create document: HOWTO be an ambassador
  15. talk with bugsquad. bugsquad is in a way a similar team. We can learn from them. write comparison with bugsquad. Communication with bugsquad is useful.

discussion of dev feedback

  • Start with a tight scope (helping with bugs,reporting important bugs to UWN) and slowly broaden the scope to the other tasks we have defined.
  • In the future we envision a lot of different tasks for forum-ambassadors such as helping users report bugs, helping users write specs, guide discussions about new specs and much more. We hope forum-ambassador volunteers will choose tasks based on skills,interest and time. We think it's a good idea to use UWN to report things like interesting threads to.
  • we want to start soon. we don't want to spend too much time on the document anymore. we'll learn as we go along.
  • It's not entirely clear to us what kind of tasks you envision the launchpad ambassadors to do. There's probably some overlap between these projects. Maybe both project can learn from eachother and cooperate on some stuff. As and when the launchpad ambassadors begin working the operations of the forum ambassadors can be adjusted easily.

Forum Council Feedback

The following link contains a summary of the meeting where the forum ambassadors spec was presented to the FC. They have agreed to recognise us and provide any assistance we require.

https://wiki.ubuntu.com/MeetingLogs/ForumCouncil/2007Feb13

nominate yourself for FA member/leader thread

first post :

About Forum Ambassadors :

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, concise 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 UWN, mailing lists or 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 : [WWW] http://ubuntuforums.org/showthread.php?t=278375

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

This news :

We are happy to inform you that we are currently in a phase of the forum-ambassadors project where it makes sense to investigate who wants to become Forum Ambassador members / leaders.

We will probably start with a tight scope (helping with bugs,reporting important bugs to UWN) and slowly broaden the scope to the other tasks we have defined.

If you are considering to join the Forum Ambassador team you should read the wiki : https://wiki.ubuntu.com/ForumAmbassadors. If you think you make the requirements you should introduce yourself and tell us what kind of tasks are suitable for you. You can find a list of possible tasks for Forum Ambassadors members on the wiki. We need volunteers to make this work :).

We will soon ask the admins to make the new forum-ambassadors project an official ubuntuforums project and team.

documentation & tools

some developers who have helped us and/or who have volunteered to give us some guidance

  • ubuntu_demon spoke to some devs in person during UDS Mountain View about this idea. This input was very valuable.
  • feedback of Sarah Hobbs (Hobbsee) has helped us during the creation of this document.

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

    • Henrik volunteers to be a point of contact. Henrik can help us a little bit for example with evaluating some reports before we send them. He can give us a bit of guidance.
    • A suggestion from Henrik : Maybe the FA team can encourage testing of cd images. This can help the devs a lot.
    • ubuntu_demon will contact Henrik 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 by Forum Ambassadors 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

  • There are no unresolved issues. There's stuff to do and discuss though. See Agenda / TODO and action plan in implementation.

Future work

  • Expanding to other Ubuntu forums
  • 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

archived commments

Archived comments: 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

  • Have you considered how the sister projects (ie. Xubuntu, Kubuntu, and Edubuntu) fit into the mix? -- CodySomerville 2007-01-08 01:11:46

    • This will be for Ubuntu and all (big) sister projects. We hope to get forum ambassador members running all (big) sister projects. Most (but not all) forum users use either Ubuntu or Kubuntu. Sarah Hobbsee of Kubuntu helped us with brainstorming. I spoke briefly to Jonathan Riddell of Kubuntu who suggested attending Kubuntu Council meetings. I attended UDS-mtv personally and we got some good initial feedback. Since then the document has evolved and we need some more (dev) feedback. -- UbuntuDemon

  • Good spec, and an important project. However, SUGGESTION - this project is extremely people heavy, I think you would benefit better by allowing forum users to do a certain amount of direct contribution. This could be easily achieved by mirroring more mailing lists. Personally, I think its vital that we work to reduce overhead by ensuring that mailing lists are read by forum users in the format that they are used to, and mailing list subscribers can read forum users comments in the format that they are used to. This would automatically help to keep forum users up to date and allow them to contribute directly, for example to ubuntu-devel-discuss. At the same time, the Forum Ambassadors team could work to complement this. --mdke

CategorySpec

ForumAmbassadors (last edited 2008-08-06 17:01:37 by localhost)