=== ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 22 Jun 18:00 UTC: Ubuntu Mozilla Team | 23 Jun 12:00 UTC: Bugs for Hugs Day | 24 Jun 15:00 UTC: Server Team | 24 Jun 18:00 UTC: LoCo Council | 25 Jun 17:00 UTC: QA Team | 25 Jun 22:00 UTC: Platform Team === nxvl is now known as Guest70739 === nxvl_ is now known as nxvl_work === nxvl_work is now known as nxvl === Seveaz is now known as Seveas === asac_ is now known as asac === ubottu changed the topic of #ubuntu-meeting to: Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 22 Jun 18:00 UTC: Ubuntu Mozilla Team | 23 Jun 12:00 UTC: Bugs for Hugs Day | 24 Jun 11:00 UTC: Asia and Oceania Ubuntu Membership Approval Board | 24 Jun 15:00 UTC: Server Team | 24 Jun 18:00 UTC: LoCo Council | 25 Jun 17:00 UTC: QA Team === ubottu changed the topic of #ubuntu-meeting to: Current meeting: Ubuntu Mozilla Team | Calendar: http://fridge.ubuntu.com/event | Logs: https://wiki.ubuntu.com/MeetingLogs/ | 23 Jun 12:00 UTC: Bugs for Hugs Day | 24 Jun 11:00 UTC: Asia and Oceania Ubuntu Membership Approval Board | 24 Jun 15:00 UTC: Server Team | 24 Jun 18:00 UTC: LoCo Council | 25 Jun 17:00 UTC: QA Team [18:59] hi! ^^^ [18:59] hi [18:59] hey hey [19:00] hi all [19:00] hmm ... gnomefreak not here yet :/ [19:00] hi [19:01] rzr: RainCT: ping :) [19:01] hi all [19:02] hi [19:02] hm, it's crowded in here. [19:02] yeah :) ... arena [19:03] I thought only few of them will be here. heh [19:03] ok .... maybe lets get started. [19:03] gnomefreak is not here, so lets push his topics back in case he appears late [19:04] where is the agenda ? [19:04] Does that mean I go first? Ok... [19:04] fta: https://wiki.ubuntu.com/MozillaTeam/Meetings [19:04] agenda https://wiki.ubuntu.com/MozillaTeam/Meetings [19:04] the meeting is open right? I'm here just for the curiosity [19:04] Tallken: Sure... [19:04] thanks to Jazzva and gnomefreak that actually made this meeting become true ;) [19:04] :) [19:04] s/that/who/ [19:05] its been quite some time since the last meeting so ... here we go :) [19:05] soren, first item is membership policy for the new team, mozilla-extensions-dev [19:05] Tallken: feel free to listen, contribute, cheer, whatever :) [19:05] ok :) [19:05] Um... that's supposed to be "so", not "soren". autocomplete... [19:06] Jazzva: ok go ahead. maybe outline the options we have [19:06] I have few suggestions. First is to auto-accept new team members with some sort of trial period (1, 3 months, ...), during which they need to prove their skills with some sort of development for the team (packaging extensions, fixing current bugs in mozilla extensions, ...) [19:07] The second would be to ask new members to show some skills before being accepted in the team. [19:08] personally, i prefer the first (open) option but would like to hear what others think? [19:08] Personally, I am more for the second option, since we probably will use mozilla-extensions-dev branches in development, according to extensions' LargeScaleDevelopment (am I right?). [19:08] i prefer 2nd but it's less critical than for m-t [19:08] i think the first option sounds best [19:09] especially the current extension-dev members ;) [19:09] * RainCT is here [19:09] yes ... LargeScaleDevelopment is later on the agenda, but since it somehow interferes with this agenda point, let me explain what we plan to do [19:09] in the first option after the trial period is needed a meeting for confirmation of the members [19:09] ? [19:10] second option is lots easier to manage, I'd say. people can always branch and ask for merges. [19:10] to better scale the extension package maintenance and help extension packagers we want to provide a few "automated" services [19:10] for instance: we will provide automatically tracked upstream branches [19:10] and try to automagically upgrade the .ubuntu branches [19:11] the result of that auto upgrade will end up in a .staging branch which is supposed to reside in the ~mozilla-extension-dev team [19:11] so the only thing that extension contacts need to do is reviewing those .staging branches and resolving any eventual conflicts [19:12] so basically the only harm someone can do is breaking the .staging branches before they get released to the archive [19:13] for me that means that its an acceptable risk if it helps us to get more contributors by removing a barrier (e.g. entering the team) [19:14] anyway. on the end both options are ok for me :) [19:14] asac: people can branch those branches anonymously (http) without any risk at all surely :-) [19:14] that also makes for needed reviews of the merges, since they have to ask for it :-) [19:14] I lean towards option 2. [19:14] Nafallo: Any m-e-d member can contribute to them, I suppose that's where the risk of breakage is... But what asac said sounds reasonable, too... [19:16] Maybe we can compromise. To try the first option for some period, and then if we don't get more contributors, then to fall back to the second option? [19:16] asac, if we auto accept (option 1), how do we get rid of people doing nothing ? (ie, those who just collect team memberships) [19:16] Nafallo: right. good point. [19:16] fta: the idea was to have a trial-period [19:16] like 3 month ... then looking if there is activity [19:16] even for opt1 ? [19:16] fta: only for opt1, Jazzva ? [19:16] e.g. auto admission == trial [19:17] fta, asac: yes [19:17] e.g. merio-admission == no trial [19:17] merito :) [19:17] Jazzva: for the risk you tell maybe setting a team policy (best practice) that a contact must push only branches of the extensions he is the contact can help^ [19:17] asac: Well, if we they contribute, I think they can be accepted to the team :) [19:17] i think the question is if extension-dev members can sign off packages that then get automatically uploaded [19:17] if there always is a review step by mozillateam members required, we can auto admit i guess [19:18] would a mentoring option work? Part of the trial would be working with someone who can monitor their contributions? not sure how many people to expect to join [19:18] JenFraggle: imo mentoring should be done in a non-dedicated fashion [19:18] asac: Is that possible in LP? [19:19] the whole #ubuntu-mozillateam channel is aleays your mentor :) [19:19] (for review thingy...) [19:19] I think we are walking a thin line here... automatically accept people for packages that potentially gets auto-uploaded? there is a reason we have policys for getting upload rights in the first place. a reviewer can always miss things in branches. [19:19] Jazzva: there is a feature where users can review/vote for patches [19:19] we could say that "two positive" votes of m-e-d members would trigger upload [19:19] or one positive by m-t members [19:19] fta: you already saw that feature in action, didnt you? [19:20] But what if those two positive votes are from new, auto-approved m-e-d members? [19:20] e.g. sign off merges [19:20] The "one positive m-t" sounds good... [19:20] Jazzva: right. thats why i now lean a bit more to option 2 :) [19:20] hi [19:20] Hey, rzr... [19:20] even if we dont implement that right from the beginning, i would at least keep the option open [19:20] to do it :) [19:21] how do other teams to this? [19:21] Well, here's one more: Let's try option 1 for 3 months, with one-positive vote from m-t and see if that goes well. If it doesn't, we can go to option 2... [19:21] the other option would be to not couple the "review-power" with team membership at all, but maintain a list of valid reviewers [19:21] surely there must be things like the desktop team that has contributors? [19:21] m-t? [19:21] RainCT: ~mozillateam [19:21] Nafallo: they go over sponsorship unless you can upload to ubuntu on your own [19:21] asac, yes, the new voting system for branch merge requests [19:21] ah ok [19:22] asac, not sure it triggers an upload though [19:22] fta: you tink its better to couple voting powers with team membership or by maintaining a manual list of reviewers? [19:22] fta: sure it doesnt ... thats what we need to implement :) [19:22] hmm. option 2 is basically sponsorship, but with branches rather than debdiffs... [19:22] (welll at least a merge to the release branch) [19:22] Nafallo: right [19:23] * Nafallo likes option 2 :-) [19:23] Nafallo: Yes, for the beginning. Then we add that contributor to the team [19:23] ok ... so what are the requirements for joining if we have criterias? [19:23] * rzr thinks branches is better thatn debdiff [19:23] * asac assumes that we settle on option 2 [19:23] Anyone against option 2? [19:24] 3, 2, 1 [19:24] asac, i'm not sure lp could restrict voting powers. I stand for option 2 [19:24] I suppose that we're for option 2... [19:24] 0 ; opt 2 is sold for 1000$ [19:24] no objection. lets go for iut [19:24] :) [19:24] ACTION: someone to draft m-e-d team requirements [19:24] for admission :) [19:25] We might want them to package an extension ;). That would be the best :). [19:25] as a criteria [19:25] ok ... what are the requirements? [19:25] no strict rules, but a vote during mozillateam meeting? [19:25] Jazzva: well. i guess that packaging an extension is a basic requirement for sure [19:25] Hehe :) [19:25] PROPOSAL: make a branch in the personal LP page with a funcional extension and the debian folder? [19:25] but i doubt that packaging an extension just once and then going away is not good enough [19:26] package an extension, or update an existing extension needing love [19:26] work with the reviewer and he would then be the best to tell when the individual is considered ready? [19:26] in this way mozillateam members can check the work [19:26] asac: Sure... Maintaining it is also good :) [19:27] 1 package + 1 bug fix would be show that he's confortable with the process [19:27] Nafallo: I think it would be good if more people could say that one is ready... [19:27] + n bug fix [19:27] i really think updating extensions should get in the equation [19:27] otherwise we will end up with zillions of branches, that nobody updates :) [19:28] asac: +1 [19:28] Nafallo: That would go in accordance with "whole #ubuntu-mozillateam is your mentor". That way more people get to meet a prospective developer [19:28] +2 [19:28] so maybe: at least 1. new extension, and 3 updates? [19:28] Jazzva: good point [19:28] having less extensions but updated ones is better than lots of unloved extensions [19:28] asac: +1 on that... with "maintaining extension" requirement [19:28] ok. [19:29] how about expiring anyway? e.g. if there is no activity for 6 month we should probably expire members too (with the option to join back whenever they want) [19:29] asac, maybe we should recommend newcomers to work in ~id/+junk/branchname instead of in the project tree, to avoid pollution. [19:29] asac: Sounds good... [19:29] IMHO there will be two different kind of members: those who help packaging extensions just for help the packaging process and those who package and mantein their own extension (extension developer). You can require that the first kind of members when package an extension have also to maintan the same extension [19:29] fta: good point [19:29] fta: can all submissions for merging be done in +junk? [19:29] asac, no idea [19:30] worth a try [19:30] hi all, I hate to say this but the documentation lacks at many a places, could something be done about that? [19:30] asac, fta: Well, it can be copied to other branch, if it can't be merged from +junk, right? [19:30] i need a few before i can talk [19:30] Jazzva, right [19:30] Volans: shirish we have an agenda item about that later :) [19:30] my connection is not working. only wireless is working it seems [19:30] I dunno if this is time or perhaps at the end of the meet, asac, fta ? [19:30] shirish: Doc? Wiki pages? That's also on agenda :) === ubuntu-laptop is now known as gnomefreak [19:31] Jazzva: yup [19:31] :) [19:31] Volans: right. i think extension authors (as in upstream) that want to maintain their package can be added to the team after they finished their own package [19:31] Hey, gnomefreak. Welcome :) [19:31] shirish, add your idea in https://wiki.ubuntu.com/MozillaTeam/Meetings, we'll see [19:31] gnomefreak: \o/ [19:31] hi Jazzva [19:31] hi asac [19:31] ok .... lets sign off the procedure: [19:31] im pissed and working on a conection atm [19:31] 1 package + 3 updates [19:32] brb [19:32] after that regular contributions of not defined amount ;) [19:32] for upstream extension authors we have an exception that they just need to have finished their own extension package [19:32] is that high enough bar for joining m-e-d? [19:33] any objectsions? [19:33] Fine by me. [19:33] sounds shiny :-) [19:33] asac, ok for "1 package + 3 updates", but coupled with resignation after 3 (6?) months of inactivity [19:33] 3 [19:33] sounds good [19:33] fta: i think 6 month of inactivity is ok [19:33] 3 updates of their packages, or any packages? [19:33] Jazzva: well ... doesnt really matter i'd say [19:33] Cool :) [19:33] 6 months is a full cycle, may be too much [19:34] fta: so you want to put more pressure on m-e-d members? [19:34] :) [19:34] fta: and if the extension they are interested doesn't get updated for the period? [19:34] we could align the review with the release time. [19:34] i just want people to feel concerned [19:34] I think 6 would be better. That way people are not under pressure of working :) [19:34] would we need to tie this to a working extension for current firefox maybe? + track upstream [19:34] e.g. review 1 month before we release ... to give contributors an incentive to do their housekeeping :) [19:34] i say 6 rather than 3 [19:35] fta: i'd say that 6 is ok if we dont really have dedicated maintainers ... e.g. everybody can work on any extension [19:35] with dedicated maintainers 6 would be too long [19:36] ok have we reached a consent? [19:36] pointer: we have a bunch of other items on agenda :) [19:36] I'm ok with this :) [19:36] i'm ok with 6 if there's nothing to do on the extension the user worked on. but if we detect new upstream versions, but no work from 3 months, i find that quite long.. [19:37] can someone post results on the meeting agenda or email me the logs [19:37] -from+after [19:37] fta: right. i'd say we review before release and decide case-by-case ... with the 6 month rule-of-thumb [19:37] gnomefreak: I can do it... [19:37] asac, ok [19:37] asac: +1 [19:37] Jazzva: thanks [19:38] anyone against having a rule-of-thumb of 6 month that can be changed by meeting decision? [19:38] gnomefreak: No problem. Are you gonna stay for your agenda items? [19:38] gnomefreak: we are still on first item: "extension dev membership" [19:38] ok lets do it that way then for now [19:38] next item :) [19:38] i doubt it i need to get a working pc other than this laptop [19:39] asac: 6 & 3???? [19:39] gnomefreak: If you can, we can do your agenda items now... or at the end of the meeting. [19:39] i'd say since gnomefreak is now here we go directly to his items (which are the first on the agenda) [19:39] Sure... [19:39] TOPIC: Team Tags and Status changes [19:40] which is "We need a set of tags to keep and others to remove or combine in other tags also i would like feedback on what wikis to update since most are old. Feedback on these wikis would be great or some ideas and i will save everything as notes for a to do list and go from there " [19:40] ok with tags i was thinking of ones we need to remove or add [19:40] i think its agreed that the current bug procedures are too formal and we should come to something more simple [19:40] correct [19:41] MT tags: https://wiki.ubuntu.com/MozillaTeam/Bugs/Tags [19:41] my vision is: keep it really simple and let most of the bug work be done by the bugsquad and bugcontrol (QA) team [19:41] MT states: https://wiki.ubuntu.com/MozillaTeam/Bugs/States [19:41] i want bug triagers to use mt-confirm instead of marking confirmed [19:41] or other tags [19:42] im seeing alot of bugs being closed for no reason lately [19:42] in preparation of this meeting - based on discussion we had with bdmurray - i did setup https://wiki.ubuntu.com/MozillaTeam/Bugs/TriagersHandbook [19:42] so far, we are really bad with mt-upstream and mt-postupstream :( [19:42] right [19:43] not sure the QA team wants to do that [19:43] fta: they want to help [19:43] (with support of mozillateam) [19:43] the upstream procedure is a topic on its own [19:43] based on UDS discussion i drafted https://wiki.ubuntu.com/MozillaTeam/Bugs/UpstreamBugProceduresIntrepid [19:44] WE should push to upstream IMHO since we know what needs to be dpone [19:44] the current topic is ment to fix the horrible situation for bug triage _before_ bugs actually get forwarded [19:44] the handbook above tries to support the upstream triage, by introducing a "standard format" of bug summaries/descriptions [19:45] (look at requirements for confirmed on https://wiki.ubuntu.com/MozillaTeam/Bugs/TriagersHandbook) [19:45] Well, TriagersHandbook looks good to me. It's quite simple - when it's confirmed, notify upstream :) [19:45] shouldn't it be both bugs and patches in a way that is easier for upstream to work with [19:45] shirish: patches are a rare case i guess [19:45] how dont they fit in the triagers handbook? [19:46] patches need to be attached to bugs, so it's covered [19:46] shirish: We might not be able to produce patches if they're deep in the code. Maybe it would be better if upstream plays with it [19:46] (at least, that's my opinion :)) [19:46] even if we have a patch that fixes something, a bug still needs to be of the proper form as upstream certainly wants a good description on what get actually fixed [19:47] true [19:47] ... so imo patches dont make the handbook unapplicable [19:47] do we want to add a hint about what to do with patches to that handbook? [19:48] asac: It might be good [19:48] ok [19:49] ACTION: add how to upstream patches to the triagers handbook and how it fits in the general procedure :) [19:49] asac, what about when a user contributes a patch, then it's posted upstream but upstream wants changes. how will the initial user know ? [19:49] it might also fit in with ubuntu-marketing to let other people know of ubuntu's contribution to packages. [19:50] fta: good question. i think one requirement is to CC the ubuntu@bugs.distro users on forwarded bugs upstrewam [19:50] we can tehn setup a mailing list that will get the traffic [19:51] so if there are questions we can react; bug the initial submitter; or look for someone who can work in what upstream has asked for [19:51] fta: is that good enough? [19:51] yes [19:51] i've got to go guys, sorry [19:51] Jazzva: cu. thanks! [19:51] Ok, JenFraggle... See you :) [19:52] ok. i think the topic "bug states" is well covered as we are already improving the wiki [19:52] and the general direction to tap more bugsquad and QA members for general triage is also consent i guess [19:52] anyone have something to add, before we move on to the next topic? [19:52] wait [19:53] lets move ahead. if anyone gets more ideas we can also move it to mailing list [19:53] shirish: ? [19:53] what about wikis that need to be updated [19:53] wasn't that part of the 1st topic as well. [19:53] shirish: we are already working on new documents that finally will replace the current pages [19:53] shirish: It's coming later ;)... It's MozillaTeam Wiki item. [19:53] ok, a link to sneak-peak ? [19:53] is that what you are asking for? [19:54] shirish: i posted them above :) [19:54] shirish: This was about bugs tags, states and triaging [19:54] https://wiki.ubuntu.com/MozillaTeam/Bugs/TriagersHandbook [19:54] no no [19:54] https://wiki.ubuntu.com/MozillaTeam/Bugs/UpstreamBugProceduresIntrepid [19:54] ok, what I meant if there is some finished work I could see of a wiki docuement [19:54] i need people to look for issues with them and let me know what needs to be worked out. we have too many wikis for me to go through and look on my own [19:54] shirish: dont understand what you mean? [19:55] ok, arte we on next topic now? [19:55] shirish: ?` [19:55] asac: that needs to be updated with UDS results [19:55] asac: I meant how the new wiki is being structured or what things are being looked at [19:55] is your question about "Team Tags and Status changes " or "MozillaTeam Wiki " [19:55] ? [19:55] asac: mozilla wikis in general for topic 2 [19:55] ok ... i am fine to move to that topic [19:55] read my post above [19:55] "MozillaTeam Wiki: [19:55] Though next one would have been "Thunderbird Extension" [19:56] asac: i can wait [19:56] asac: we can work out tags and status' more on ML or in #u-m-t [19:56] ok, lets push that back and go ahead with "MozillaTeam wiki" [19:56] gnomefreak: right [19:56] ok [19:56] TOPIC: "MozillaTeam wiki" [19:56] RATIONALE: We need to clean up the wikis for the MozillaTeam, for example taking a wiki that has conversations posted should be changed to a complete wiki, this will help users understand it more. All MozillaTeam's and ExtensionTeams's wikis should have CategoryMozillaTeam, CategoryBugSquad at the bottom of wiki page [19:56] asac: im not looking at agenda page [19:57] i think nobody will disagree that we should add the Category everywhere [19:57] anyone volunteers to do this work? [19:57] asac: thats about the jist of it, also need old wikis that freddy and alex were working on need to be updated also davids wikis [19:57] If it's not important atm, I can help in a week or two... [19:57] asac: i will [19:57] e.g. every mozillateam page gets CategoryMozillaTeam and every MozillaTeam/Bugs/ page gets CategoryBugSquad as well? [19:58] asac: i need to get things worked out before hacking the hell out of them though [19:58] can help with that. [19:58] asac: no [19:58] well maybe [19:58] shirish: great. [19:58] ok so [19:58] there is one thing more which bites me though [19:58] ACTION: properly categorize MozillaTeam wiki pages [19:59] many of the pages don't follow a particular structure [19:59] asac: you want to use cat.bugsquad and mozillateam cats.? [19:59] shirish: thats why i have been working on them [19:59] please note this is not just with the mozillateam but with all. [19:59] gnomefreak: thanx [19:59] shirish: we had 2 people doing wikis and they left [19:59] gnomefreak: al pages that belong to mozillateam get MT cat ... the Bugs/ pages get bugsquad category on top of that [19:59] * gnomefreak only concerned with our at this time [19:59] asac: ok [20:00] it would be nice if we had a place for people to know what or how they are expected to write, some structure documentation is good. [20:00] shirish: want to become the official wiki lead for the mozillateam? [20:00] :) [20:00] ours need more work than bugsquad [20:00] asac: thanx for the offer, but would decline, of course would help with whatever little I know or can do. [20:00] shirish: i ment: "take the lead on wiki cleanup" :) [20:01] gnomefreak: perhaps we can collaborate on this [20:01] asac: i got the lead once i have a working connections the power outage burned up something [20:01] basically means: going through, looking if things still apply; if in doubt ask on ubuntu-mozillateam [20:01] shirish: yes that is fine :) [20:01] and remove outdated things [20:01] ok [20:01] asac: right, that's not an issue [20:01] ACTION: gnomefreak and shirish work together on initial MozilaTeam wiki cleanup :) [20:01] biggest wikis are membership, bugs, states, tags [20:02] asac: apart from that [20:02] if we could have just some idea for a newbie who wants to put stuff on the wiki what goes where, how and what [20:02] asac: just need an outline of what tags you would like to keep. and what ones to dump so get with me on this once im on my desktop [20:03] shirish: wiki in general orformat of ours? [20:03] shirish: we can offer to help users to find the right place in #ubuntu-mozillateam or on mailing list [20:03] gnomefreak: ? [20:03] i think its hard to write a proper documentation that covers enough cases to be really useful [20:03] right. Lemme explain what I mean [20:03] shirish: if we could have just some idea for a newbie who wants to put stuff on the wiki what goes where, how and what [20:04] lots of wiki pages which are there are disconnected to the projects from where they came from or what's happening there. [20:04] gnomefreak: I meant ur answer "wiki in general orformat of ours?" [20:04] shirish: thts why we want to add the categories [20:04] shirish: https://wiki.ubuntu.com/CategoryMozillaTeam [20:04] those are all pages that claim themselves that they belong to mozillateam [20:05] you basically add that to the bottom of the page [20:05] asac: I know that [20:05] ah :) [20:05] be right back erin is having connection issues as well :( [20:05] what I meant was more precise let me take an example to explain what I mean [20:05] now let's say w.u.c/wiki/Webkit [20:06] now while Webkit gives a surmise of what it is, it doesn't give any link to www.webkit.org or any blogs or anything of the developer who's developing upstream [20:06] shirish: There's a link at the end of the page :) [20:06] now while Webkit wiki page gives a surmise of what it is, it doesn't give any link to www.webkit.org or any blogs or anything of the developer who's developing upstream [20:06] ok [20:07] shirish: i think such quality standards should be enforced outside the mozillateam [20:07] we can only come up with policies that are mozillateam specific [20:07] right but there could be many more so it makes for people interesting for the project. [20:07] e.g. if you make a firefox extension page, do this, that and whatever :) [20:07] shirish: i think the right group to enforce and draft such general policies would be the Documentation Team [20:07] asac: +1 on that [20:08] ok cool [20:08] shirish: could you look which pages of the MOzillaTeam might fall into a category that could benefit from such general procedures? [20:09] asac: not at the top of my mind, but yes for sure. [20:09] good [20:09] ok. i think thats it for wiki cleanup topic for now? [20:09] gnomefreak: ? [20:10] as it fits to this discussion, I'd suggest to move to "Extensions related wiki pages " [20:10] TOPIC: Extensions related wiki pages [20:10] he said something about connection issues [20:10] Jazzva: ? [20:10] Right :) [20:10] fta: ok. lets discuss this with him outside the meeting and followup on mailing list [20:11] k [20:11] Jazzva: what do you suggest regarding extension pages? [20:12] I was thinking of setting up extensions' related wiki pages under MozillaTeam/Extensions/, so they're not mixed with the general MozillaTeam pages. For example. Current MozillaTeam/Firefox3Extensions/Packaging would be MozillaTeam/Extensions/Packaging, and MozillaTeam/Firefox3Extensions could be ... dunno, MozillaTeam/Extensions/List [20:12] Jazzva: so you want to remove "Firefox" from the context? [20:12] we should do that but in sense of a firefox one a tbird one ect... as main pages [20:12] e.g. remove it from wiki name [20:13] gnomefreak: + [20:13] That would also apply to the rest of the pages that are related to extensions' stuff. I don't think there will be many pages to go to the MozillaTeam/Extensions/, on the other hand [20:13] this way we dont have ff and tb messed in one page [20:13] asac: gnomefreak's idea is good [20:13] Jazzva: just keep our heading and add to that [20:13] so MozillaTeam/Extensions/Packaging (e.g. for general mozilla extension packaging) [20:13] ehrm. so s/3//g ? :-) [20:14] and MOzillaTeam/Extensions/Firefox/List (for firefox 3 extension list) ? [20:14] leave MozillaTeam/firefox/extensions band so on [20:14] ah [20:14] Yep, something like that... [20:14] asac: replace list with the autual pages [20:14] gnomefreak: one page per extensions? [20:14] actual [20:14] hmm [20:14] and for other mozilla programs? (seamonley, ecc..) [20:14] i like the table [20:14] Thought, we need to know what to do with extensions which both work in FF and TB [20:14] asac: no one page per firefox extensions [20:15]