View Single Post
Posts: 1,513 | Thanked: 2,248 times | Joined on Mar 2006 @ US
#20
Originally Posted by Jaffa View Post
I think Dave's point is longer lived than right now. Managing the maemo.org staff is not the job of the council - we're customers and stakeholders who want "things" done in a timely and open way. By moving to a position where we state our requirements and it's up to the team to organise themselves to deliver them, alongside their internally generated requirements (BAU) and Nokia priorities.

As Dave kick started this, the council was discussing with Niels (X-Fade) the handover of the administration of the sprints to the maemo.org team themselves.

The council, and Nokia, would feed our priorities into that process - and the process would be open for everyone to see as the team split up the tasks, take ownership and deliver them. Volunteers from the community would be able to chip in in either specific areas (and the council can act as a rallying point if needs be) or on whole tasks of interest.
OK....

Council doesn't have to manage the details and administration, and can leave it to staff to decide how to accomplish tasks, but it should mark that it is out-of-bounds for staff to directly ask Nokia for permission to spend paid time working on projects outside maemo.org for the two reasons that I mentioned.

And at least one Council member should be at available for the monthly sprint meetings.

Originally Posted by Jaffa View Post
With that, some of the requirements from the Council are, in rough priority order:
  1. Finalise SSO for maemo.org; including Talk account merging.
  2. Bugzilla easier to use (requires upgrade?):
    • Bugzilla style improvements
    • Bugzilla voting improvements ("me too" button?)
  3. maemo.org/packages/ QA improvements for maintainers and testers
  4. Consolidated documentation for developers (see Info Center thread for my thoughts)
  5. Autobuilder auto-optification
  6. Donation framework on maemo.org for authors to accept donations, if they so wish

Items #1 & 2 have no real benefit to a future MeeGo transition, but meet immediate problems. Item #5 may help as appplications are increasingly written with tools like Nokia Qt SDK and we need the auto-builder to improve them.

The others will give experience we can translate to meego.com, and possibly even implementations.
some quick thoughts - #1 has vexed us for awhile, and #2 is now questionable since we seem to be facing an end to bug fixes with MeeGo coming. At least #1 is useful in the future. I would add trying some project to bridge maemo and Meego, if possible, such as through stskeeps MeeGo adaptation for N8x0 devices replacement for Mer, Mer^2...
And while it is good, we shouldn't yet require that projects must have experience that can translate to meego.com, IMHO
__________________
3-time Maemo Community Council Member
Co-Founder, Hildon Foundation