ForumAmbassadors

Revision 40 as of 2006-12-10 16:50:27

Clear message

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.

==Who's here and Who's who: -Maniacmusician Sarah Hobbs - Hobbsee Toby Smithe ubuntu_demon also starring: 23meg

  • boooo hisss

BuffaloSoldier PriceChild dvarsam (i.e. dimitris)

Agenda / TODO

  • CLEANUP the document
  • work through the document section by section
  • look at criteria and tasks for Forum Ambassadors. Particularly regarding 1) how they should intereact with users 2) combing through forums 3) how the subforum works 4) activity in development section of the forums
  • work on defining reports/reporting
  • define what sort of email should go to ubuntu-devel / ubuntu-devel-discuss in == design ==
  • list of concrete examples. When should a FA act ? How should this process go ?
  • discuss unresolved issues
  • CLEANUP the document
  • any other items ????

Summary

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

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

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

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

Forum Ambassadors might become a team like : http://ubuntuforums.org/showthread.php?t=289810

ubuntu_demon : please keep the summary concise and short and leave out implementation and design details.

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. 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. 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 "the developers don't browser here" strung all over the place in bold font. They are told to "file a bug", post to the mailing list, and this may seem daunting in this radically different world. As well as making it easier for the developers to reach the users, the spec tries to make the users able to reach the developers.

Use cases

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

Scope

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

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

  • The focus of this team should *not* be to try to educate every new user, although the team would assist in communication between forums users and developers. This spec is not about creating a team to help new users. We 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. We can use another team for this. Both teams can learn from eachother.
  • This spec is *not* about creating documentation.
  • Initially intended for ubuntuforums.org. In the future other Ubuntu forums can possibly learn from us or possibly even join us. For now expanding to other forums is out of scope.

Design

  • Forum Ambassadors Team consists of Forum Ambassador "Members" and Forum Ambassador "Leaders". See tasks,criteria for both "FA members" and "FA leaders".
  • about FA "Leaders":
    • - start with three (3) FA leaders - we defined some criteria and tasks for FA leaders

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

  • define Tasks of Forum Ambassador "Members", discuss evaluating requests and give examples of things a FA could do:
    • - See Use Cases.

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

  • define Criteria for Forum Ambassador "Members":
    • - respect and follow CoC (Code of Conduct) - amount of time dedicating to it *entirely* up to yourself - if stepping down then stepping down gracefully - willingness to learn and enthusiasm - shown to be capable and respectful in interacting with community members on forums - having a sense of what is feasible and what isnt. Having a vague idea of how things work is also useful. - if time available then be willing to go to UDS if sponsored - Forum Ambassadors should have a rough idea about what happens on k/x/ed ubuntu-devel (pick the one you like) - ability to filter requests from users (support request (let staff move it), bug report, feature bug, spec, obvious idea,..)
  • define Tasks of Forum Ambassador "Leaders":
    • - being a regular Forum Ambassador - making sure FA "Members" live up to the criteria - solving inter-FA-team problems if any - communicating with forum staff if needed
  • define Criteria of Forum Ambassador "Leaders":
    • - the same as for FA

      - respect and follow LCoC (LeadershipCodeofConduct) - (extra) community experience helps - extra criteria up to the forum admins - appointed by forum admins

  • Goals to achieve
    • To encourage and assist forum users in bug reporting, writing specs and launchpad. Point them to docs and help them if that doesn't suffice. If there are no docs, ambassadors should help them along; and let someone of the docteam know 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). (Get the active members to join the project)
  • When users should 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. help reporting bug when 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 the user that this is an obvious idea and therefor not worth reporting to the developers (they are swimming in bug reports and email already). - prioritizing some spec (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 tdmihe 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. - "unclear what user wants case" => more information needed from user.

  • 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 general direction users feel the next release should emphasis on

  • define appointment of FA "Members" and FA "Leaders":
    • - people can nominate themselves for FA "Leaders" and FA "Members". - FA "Leaders" appointed by Forum Admins. FA "Members" put forward to Forum Admins by FA "Leaders" and appointed by Forum Admins.
  • define structure of launchpad team: - moderate team - FA "Leaders" should be the LP admins, who have the power to approve/deny candidates, and who automatically receive all bugmail from +subscribed bugs.
  • define what kind of mail should go to ubuntu-devel:
    • - urgent bugs - reports with compilation of things the FA did -?
  • define what kind of mail should go to ubuntu-devel-discuss:
    • - discussion items such as ideas,specs,... - some bugs ? define what kind of bugs - 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 reports:

  • -

* 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)
  • meetings: - we have: 1) forums and 2) irc for communication - it might be a good idea to do a weekly irc meeting (especially in the beginning)

Implementation

main

action plan / what to do before creating this team

  1. work through the agenda today
  2. ubuntu_demon will blog to planet.ubuntu.com and will send emails to ubuntu-devel and ubuntu-devel-discussion asking for feedback on this document
  3. as much gobby sessions as needed to solve unresolved issues and to incorporate dev feedback
  4. people should nominate themselves if they want to be FA members. Now that we know what this is based on the last document.
  5. people should nominate themselves whether they want to be FA leader.
  6. ask the admins to review the document and give their feedback
  7. ask the admins for a forum section and ask them to create the forums team. They will appoint 3 leaders. There will always be 3 FA leaders.
  8. 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-7 are done.
  9. 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.
  10. This document is only a draft. The final implementation is up to the admins and Forum Ambassador Leaders (appointed by the admins).
  11. The FA will mostly use ubuntu-devel 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.
  12. We have defined some criteria that have (at least) to be present in Forum Ambassadors and Forum Ambassador Leaders. The admins should appoint one or two 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.
  13. 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.
  14. The FA team should start small (about 5-7 depending on the amount of capable volunteers) and slowly increase in size.
  15. Create Document HOWTO be an ambassador
  16. create ambassador team leaders
  17. FA don't need specific tasks. forum moderators don't have specific tasks and this works out nicely. Let's try to the same dynamic approach for FA also.
  18. 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

  19. 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.
  20. 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!
  21. (potential) Forum Ambassadors don't have to be afraid to talk to developers. They will gradually learn what kind of information is of most interest to the developers. Forum Ambassadors should try to filter out obvious and useless ideas. Forum Ambassadors should try to keep the number of emails to ubuntu-devel low since developers are already drowning in bugreports and email.
  22. 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)
  23. We should try to have at least one FA at every (Kubuntu/Community) council meeting and report there (briefly). (idea by Jonathan Ridell)
  24. Maybe FA should automatically be subscribed to new specs at the next UDS ?
  25. 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]

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 (devel mailinglists, developer forum section, FA forum section)
  • posts in ubuntu-devel, kubuntu-devel,xubuntu-devel,edubuntu-devel, ubuntu-motu and the new FA forum section are readable for everyone
  • report to Ubuntu Weekly and ubuntu-devel on an irregular basis (maybe regular later)

Unresolved issues

  • weekly irc meeting of Forum Ambassadors ubuntu_demon: suggestion by me. What do you guys think ?
    • maniacmusician: I agree. I would also like to see a fortnightly alloted time slot, or at least every three weeks. instead of weekly ? no. weekly meetings are cool. Time slots are for like...reporting stuff. sending stuff to the developers.

    I don't know how much free time you have but IMHO a lot of potential FA (like me) sometimes have some time and sometimes are very busy for a couple of weeks. IMHO we should make as little time requirements from FA members as possible. A weekly meeting would be nice .. but after a little while it should go to a weekly 1 hour meeting and not whole days like today Smile :)

Maniac: I'm not disagreeing with you, but I think there should be some loose, flexible schedule. We should send stuff for the devs on some kind of schedule. once every 2 or 3 weeks maybe. I dont want to enfornce some kind of strict regiment. and I never disagreed with weekly meettings. I also would prefer small 1 hour meetings Smile :) part of the reason this takes so long is waiting for gobby to stop lagging. dimitris - well this is also why we would need 3 FA leaders too!!! How do you expect them too to be available on every FA meeting? Once every 2 weeks is better I guess! BTW - when a new release is out, there is going to be more troubles compared to other times... One hour meetings? This is not enough for sure! - even now we are talking for 4 hours and still cant decide on everything! Two hour meetings at least...!!! thats becasue its gobby and because its a huge document. 1 hour is plenty to just review the stuff collected and make sure everyone is doing okay. Have you ever though of some FA member suggesting to implement AIGLX & the rest of FAs not really know what the heck this truly is?this is truly irrelevant. FA members do not make suggestions, they collect and report. thats it. really? I though that collectors were picking up suggestions & bringing them in the FA meetings...-kind of, but we just collect it and then report on it. we dont change it to reflect our views. We report what the users think, not what we think. What about evaluation? How are you and me (if being FAs) are going to judge whether the proposal would be good to send to the devs?please stop typing. Moving to unresolved issues

You think that time will not be required for others to evaluate the proposal suggested? dimitris - I know, if we could all chat by microphone it would be much better!

  • - PriceChild: weekly to begin with, then less as time goes on. - PriceChild: I'm happy with weekly. Its not the end of the world if not everyone turns up. Don't make it a habbit though Wink ;) Would be nice if FALs always do though. dimitris - Information/Suggestions (for imporvement) given to the developers will be according to the "priority" list created on the above FA leader meatings. ubuntu_demon : sometimes priorities make sense. not always. well we have to defin this then. I thought priorities were based on what the users complained about the most or the idea that was supported the most. Of course bugs and stuff take priority over both of those.

- IMHO users should only start threads with a specific request ot the FA. Polls and discussion threads should be started by FA. IMHO we shouldn't bring everything from the current development section to the FA section then it becomes chaotic and unmanageable.

  • dimitris - Polls are fine to be performed by users - not a good idea to change this...

But Forum Collectors, collect info on user's responce on the Polls & on the FA meetings, they discuss the User's Poll results & prioritize ideas. Example: 1. A Poll is created on "Changing Ubuntu's Themes" 2. A Poll is created on "Networking not working" Both Polls get user's votes that should be improved! Which of the above suggestions is "MORE" important? That is what I call "priority" - Forum Staff need to "filter" what is good & should be forwarded to the programmers & what is NOT good.

  • - Some people are comfortable collecting information. (Collector) - Some people are comfortable diseminating information. (Disseminators) - Some people are comfortable contacting the Developers. (Developer Contact/Communicator) - No one is forced into a specific role. This is uncomfortable, and things work best when people can do what they are good at and enjoy.
  • wiki.ubuntu.com/ForumAmbassadors for full/old discussion.
  • What do other distros do regarding ambassadors ?
  • Need feedback from developers on what they would like to see in this spec. ubuntu_demon : I will post to my blog (goes to planet.ubuntu.com) / on ubuntu-devel about this spec to try whether we can get some useful input.

* request launchpad feature to somehow represent bugreporter and "user who experiences bug" ???

  • ubuntu_demon : Sometimes the bug reporter is not the person who suffers from the bug but merely the person reporting it. Launchpad doesn't have a way of reflecting this. IMHO it would be nice if we could report bugs for others without looking like us suffering from it. ubuntu_demon : I will move this to unresolved issues for now. I might file a bug for this :).

    PriceChild: I don't think that this is in the spirit of bug reporting. Also, it would be a pain due to forums and Launchpad not being integrated. The initial reporter wouldn't have an account. ubuntu_demon : Launchpad and the Forums will become integrated. I hope that we will soon see a shared login. Right now when my girlfriend has a problem I have to report it and it seems to be my problem instead of hers. (if my girlfriend were a forum user it would be especially nice to link to her support request on the forums) ubuntu_demon : let's leave it unresolved for now.

  • Whether to give credit for bug reports to users who discovered the bug or those who report it (namely the ambassadors).
    • -- we can solve this by reporting a bug to make it reflect both in launchpad.-You misunderstand. I wasn't proposing it as a a thing for discussion. We have a lot of comments on this, so let's delete the comments and leave the bullet, to save spaec and make it easier to read.
      • --- but do you agree we can solve it if malone reflects both the user affected and the FA who reported it ?

maniacmusician : As far as I'm concerned, this is still mostly an unresolved issue that could use furhter discussion LATER.


let's summarize/clean up the discussion then (but I don't have more time right now)

  • -- We probably need to file a bug to malone with a feature request.
    • we would want to be able to submit bugs for others and make clear that it's not our bug. Let's put this to unresolved issues if it's not there already.

      - ManiacMusician : I see. I don't think that matters in our case. We will probably file bugs under the name "ubuntuform-ambassadors" or something like that, so obviously they won't belong to us. And i don't feel kindly about giving credit to people that don't want to do research and figure out how to submit a proper bug and then want credit for the submission Smile :)

      • - PriceChild : I REALLY like the idea of one name for all bugs from the forums as That would really show what we can do.

        • - UbuntuDemon : would be nice to show "Forum Ambassador team member xyz has reported this bug for user zzzxxc" Smile :)

          • - ManiacMusician : eh. It detracts emphasis from the team and may cause some people to try and compete.

            • -ubuntu_demon : IMHO it's better than not seeeing the username of the user with the bug at all. - ubuntu_demon : let's leave it unresolved for now.

dimitris - This is ok with me as long as you have users coming to us!

  • But we also need another mechanism where we (i.e. FAs) aproach them too! And that means that FAs visit the subforums named "Development (Feisty Fawn)". At least, this is a job of what a "FA Collector" should do. ubuntu_demon : it would be nice if they visitied the development subforums once in a while. IMHO we shouldn't require it see criteria-but aren't we going to comb the whole forum anyways? once in a while. So the development subforums are part of that. I think there;'s really no need for this comment and it can be deleted. I think we've already stated this in our plans elsewhere. if it is stated elsewhere - then delete this - no problem. dimitris - If we don't require it - then how do you suggest FAs collect new ideas coming from the users?

Either we shut it down (bad approach), or we visit it often (much better)!

  • I'm not saying shut it down. I don't get this reasoning. I meant that: if you do not want FAs to collect ideas from the "Development (Feisty Fawn)" subforum, then you must "force" users to post their new ideas/suggestions inside the FA subforum instead... Choose how you want to go on this...

    I think it is better to require FA collectors to visit the "Development (Feisty Fawn)" subforum too!, than to shut it down & "force" users to post new ideas on the FA subforum. ubuntu_demon : if a FA member helps some people with bug reports. Why would we require from him to go thorugh the development section of the forums ? All FA members have their own interests,capabilities,skillss because that is where users post their new ideas/suggestions!!!I think information will be collected from everywhere, not just that forum. But including it, and other places as well. maniacmusician: My Final Line: We will be collecting information from everywhere and not just the dev subforum. So this is unncessary and should be deleted. So you are saying that users can post their suggestions everywhere? This could lead into chaos! On the contrary, when Forum Staff see user posts with ideas/suggestions, the should move them in the development section! ubuntu_demon : it depends entirely on the capabilities and skills of a FA. Furthermore a FA is a volunteer. We should make as little requirements as possible. I'm not saying some FA members can't go combing through the forums. Then how are they going to collect their ideas from? stop typing

    Its like you opening an office & just waiting for users to come in!!! You stopdon't visit the customer - but just wait for him to come in...stopstop ubuntu_demon : users should come to the FA subforum and post their requests for help there. THat will be more than enough work for us.We can't require from FA members a certain amount of time to spend on it. Sometimes I have 1 hour in a week left. Sometimes I have a week of vacation I can devstop stop stopote to ubuntu stuff. STOP TYPING! dimitris - All Forum Ambassador "Leaders" will arrange & attent a weekly/bi-weekly meeting where all collected feedback from the users will be discussed & assigned "priority". ubuntu_demon : bi-weekly is too much. yes. IMHO the agenda of the meeting can be set at the meeting. Priorities are not necesserily alwas discussed.

bi-weekly - e.g. I mean once every 2 weeks! ah. Did I say it in the wrong way?

Brain Dump

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

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

== Future work ==

  • Expanding to other forums

archived commments

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

TobySmithe: We need to decide whether to have a special forum or not. maniacmusician: Yeah, we should. It will ease the load up a bit on us having to run around taking notes if people come to us

dimitris: Well there is a difference between an FA subforum & the job of a FA Collector member (e.g. An FA Collector usually visits the subforum "Development (Feisty Fawn)" to find new suggestions from the users. dimitris: Although, other FA staff can visit the other subforum named "FA". dimitris: We MUST use 2 subforums: "FA" & "Development (Feisty Fawn)". dimitris: Bugs are reported in the "FA" subforum.

  • TobySmithe: We should encourage people to use Malone as much as possible.

dimitris: What is "Malone"?

TobySmithe: See what I mean! This is one purpose of this team. Malone is the launchpad bug tracking system.

dimitris: But I thought that the purpose of the FAs was to report bugs too!

TobySmithe: Yes, but doesn't it also help others to do that themselves? Otherwise this is a lot of work. 23meg: Teach them to fish...

dimitris: I am already using "bug report" tool - just didn't know that it was called "malone". dimitris: I agree with you - well then let me rephrase: dimitris: Users contact FAs to report really serious bugs! dimitris: Not small ones - bugs that require an urgent attention! dimitris: That is why FAs need to arrange meetings where they discuss & prioritize feedback coming from users. dimitris: We don't want to throw too much work to the programmers... dimitris: We need to grab their attention to what need "immediate attention-fix".

dimitris: New ideas are reported on the "Development (Feisty Fawn)" subforum. dimitris: He collects all the info, summarizes what users want & provides all collected info to the FA staff. dimitris: Then there must be an FA meeting arranged (weekly or bi-weekly) so that all the FA staff can prioritize where the programmers should focus more. dimitris: After all FA staff agree on things that should improve, then we contact the programmers!

  • 23meg: A poll may result in "over-democratization"; users may feel as if the poll results will guarantee that things will move according to popular desire. It has to be made explicit that this won't be the case. Hmm.. People should have learnt this by now Big Grin :)

    • tsmithe: You'd be surprised Smile :) dimitris - That is why we will have a "screening" process arranged/performed by FA staff. Hobbsee: Things happen when someone is interested in implementing them. no wand waving. 23meg: Unfortunately they haven't; many are under the impression that the Development Release section of the forums is where development discussions mainly take place. Having feature discussions started by ambassadors (who will appear somehow "official"), together with polls, may deepen this misunderstanding. Right, so we'll just make it clear that this isn't the case. It can be made explicit with a section header warning.

      • tsmithe@ People will always misunderstand. Even the bold text is ignored! 23meg: Welcome to forums. That's part of the reason most devs don't read them :P Yes, and if we are to attemt bridging that gap, we have to take care to define what we're doing clearly. maniacmuscican: Yes, we will do this. I don't think there's any argument about that. tsmithe: How do we do this? [... see above]

Comments

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


CategorySpec