[email protected] wrote: > Hi, > >> ANNOUNCE: http://wiki.meego.com/Proposal_for_a_Repository_working_group > ... > >> Mission >> >> The Repository Working Group (RWG) would define and oversee >> implementation of >> the strategy for publishing community created software with the MeeGo >> project. >> >> The goal of the RWG would be to unite the various community >> contributions >> interested in applications & libraries, packaging, policy, QA processes, >> building, etc. > > It sounds like a good description of the goals of the "Extras / Downloads > team" (final name to be defined) proposed at > http://wiki.meego.com/Community_working_group#Web_infrastructure > > Is there any reason why this team couldn't be part of the Community WG? It's > all about community software.
I was going to say "I don't really have an answer to this".... but I've given it some thought and changed my mind :) Of course we can have a single over-arching community WG which handles all activity not handled by 'Core' - which is pretty much the definition of community. Inside that we can have 'teams' and instead of asking the TSG to create new working groups we ask the Community WG to create new teams... and then this proposal already has a number of sub-teams... But this distances those sub-teams->teams->Community WG from the Technical Steering Group (note 'Technical') and for this proposal I think that is a huge problem. So that's one counter-argument. The RWG is about identifying the two areas of the Meego Distro - the 'Meego supported' area and the 'Community supported' area (ooh, I like that, I'll update the proposal) : like most linux distros, Meego will inevitably consist of "Meego supported packages" and "Community supported packages" this proposal is about the latter. This again feels out of scope for what I see on the CWG wiki page. So that's two. On a more subjective note : the conversations, focus and passion *I* saw in the Community WG were 99% about more 'people oriented' aspects of the community (forums, events, building involvement and resolving human issues). This is amazingly important ..... and so far away from the nit-picking precision work that goes into policy, QA and the like that I'm not convinced it makes sense from that angle either. That's three :) I personally see the CWG (OK, I know you don't like TLAs but my fingers are getting sore!) being less technical, more forum-oriented and more focused towards users; the RWG is more technical, more email/irc oriented and more focused towards developers/maintainers. That could be a repeat. Finally: I would be concerned that having a single WG covering all the stuff on that page would not allow sufficient focus - as I said, we already see this area as being large in its own right. Think about what kinds of attendees a CWG irc meeting covering everything on that page would have!!! So that's four (ish). So yes I think that there *are* reasons why it's not part of the community WG. On reflection I even think the RWG should take responsibility for the *use* of a few of the items listed as 'web infrastructure' [1] in the Community WG: * Bugzilla - implicit in the QA elements of the RWG * Extras/Downloads - explicit already * Gitorious - kinda implicit in the process * OBS - explicit already However I think it still makes sense for those areas to be co-ordinated by the CWG Infrastructure team (singular). This would handle requirements from the RWG and would somehow arrange for those features to be funded[2] if possible. Eg if the RWG asked for automatic commit to OBS for gitorious projects with [RELEASE] in the commit message then the CWG infrastructure team would manage an implementation team. Similarly the CWG infrastructure team has to care about harmonised branding, SSO, bandwidth etc. However I don't want the infrastructure team deciding what values a bugzilla dropdown should contain. (And lets be clear - that's describing a team role, not a person.) More comments on the teams: * Bugzilla - I want this team to be tightly integrated with the QA/process/policy development. When policy rules are made we need the arbiters of those rules to see the impact on the recipients and have immediate feedback into the policy. * Gitorious - I wasn't sure if we'd be having our own VCS repos. Whether we do or don't I feel that the best-practice of DVCS integration would belong in the RWG - but SSO integration would be in the CWG infra team. * OBS - similarly the OBS is just a service - how it is used is policy, keeping it running is infrastructure. Oh, I would be astonished if people from the infrastructure team weren't involved in or even leading the RWG - and of course making the RWG a top-level WG does not reduce the need for very close interaction with the CWG. Does that convince you? David [1] The fact that these areas are 'merely' web infrastructure and mailman is on the same level as everything in the RWG reinforces my concerns over the priority focus. This is an extra counter in case you don't like any of 1-4 :) [2] as a suggestion it may makes sense for the CWG to be the community finance center too. -- "Don't worry, you'll be fine; I saw it work in a cartoon once..." _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
