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.


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

Our intended target is that the Forum Ambassadors become a team like : (If this doesn't happen we will become a 3rd party section)


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


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


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.

Criteria for Forum Ambassador Members

  • respect and follow CoC (Code of Conduct :

  • amount of time dedicating to it *entirely* up to yourself
  • step down considerately according to CoC (Code of 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 :

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


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

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

nominate yourself for FA member/leader thread

first post :

About Forum Ambassadors :

We will create a forum section on 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]

Our intended target is that the Forum Ambassadors become a team like : [WWW] (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 : 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 (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


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


  • 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


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