User:Mdomsch/SWG Spins

From FedoraProject

Jump to: navigation, search

Contents

Status

  • 2010-02-28: Spins SIG answers received. Evaluating and coalescing responses.


The Spins SIG would prefer to be able to have each Spin define it's own target audience, not per-se conform either one of the target audiences for the Fedora Project as a whole. They also want us to stop asking them about target audiences.

There is a lot of distrust spun up around this idea of target audiences. Most people don't see the point - but do see it as a way to codify why group A or group B would "win" any particular argument or splitting of resources, and everyone is afraid they'll be in the "losing" group.

Summary

  1. Yes, each Spin thinks it defines its own target audience, mostly a subset of the larger Fedora audience, though they want the flexibility to look outside whatever the Board decides is the audience. Specifically _not_ a subset of the Fedora Desktop audience.
  2. Requiring only use of content in Fedora repositories is not overly restrictive.
  3. Spins believe they are reaching their target audiences, few technical problems.
    1. Alternate Desktop spins desire to drop the compliment of GNOME apps that are "forced upon them" as a requirement of system-config-keyboard and anaconda's dep chains. This is a technical challenge, which could be resolved, but there is also a general distrust of the GNOME developers to make such changes.
  4. Resources are somewhat sufficient.
    1. Hosting for direct downloads of spins is requested, as well as stats of downloads.
      1. FWIW, FI is open to this, hosting on alt.fp.o/pub/alt/spins/ and just needs to "make it happen". mmcgrath and I have been discussing implementation details. Will need some web team love to add links too.
    2. pressing Spin media to give away at specific events
    3. more AutoQA-type work to include spins
  5. Spin to Remix: not a concern.
  6. Stop reminding them that spins are second-class compared to the Default spin. They know this, they don't like it, but they don't like to be reminded of it either.

Spins Pain Points (advisory-board Feb 18-22, Spins SIG questions, Spins Owners questions)

These are pain points expressed in the thread.

  1. Spins not well represented on the get.fedoraproject.org web page
    1. Mo proposed, at a minimum, replacing the blue boxes on the top right with links to spins.fp.o. Agreed by Darren VanBuren, Paul Frieds, and Adam Miller.
    2. Unclear who has the action item to do this. Website team?
  2. Who does QA of the Spins? Spins feeling they aren't getting QA resources.
  3. Where can spins be hosted? Spins have not felt that Fedora Infrastructure would host their content.
    1. mmcgrath offered alt.fp.o.
  4. Discontent that the "Default Spin" (e.g. the Desktop spin) is not managed in a well-defined process.
  5. Discontent that the "Default Spin" is not open for renegotiation from time to time (competition among spins to be the "default spin"; procedure to decide which is the "default spin")
  6. Discontent on insufficient resources for Spins (or ambassadors, or the project) in point comparisons to others.
    1. we have limited dollars to spend, others have more or fewer dollars to spend - yet each decides how to spend them, not all alike.
  7. Discontent that Spins aren't getting sufficient attention from marketing.
  8. Technical challenge: Spins are required to include system-config-keyboard, and must be installable, which means including anaconda. These then pull in a lot of GNOME dependencies, which the alternate desktop spins chafe at - it means less space available for their desktop bits. And distrust that the dominant GNOME development focus means technical changes won't be made to remove this dependency chain.

Specific questions

  1. Feedback received from Kevin Fenzi, seeing no huge obstacles to Spins, and their setting their own target audience.
  2. Feedback received from Bruno Wolff III, suggesting some package changes (e.g. to games) would help.
    1. This can be done through the package maintainers, escalating to FESCo.
  3. Feedback received from Jeroen van Meeuwen. Yes, spins must set their own audience. "'ve not heard of a Fedora Spin that has had any problem reaching their target audience, related to the Fedora Project. The new spins.fp.o website has helped spin maintainers and enthusiasts reach their respective target audiences way better then ever before, though."
  4. Feedback received from Chitlesh GOORAH (FEL). "What I fear is surely microelectronics engineers will not be a target audience so would Fedora Board provide the same support to us (FEL contributors) ? Last time Fedora Project leader Paul Frields deleted (twice) FEL's 50 word paragraph from Fedora-12 Talking points because it was not targeting broad users. I'm pretty much less motivated by the recent attitude."
  5. Feedback from Luke Macken (Security Spin). Board should not set target audience. "The audience is a by-product of our work, and is not a result of some initial pre-defined audience target." No technical barriers hurting him. Request for additional rel-eng/infra resources. "It would be nice to have a service within our infrastructure that would do nightly composes of all spins, perform analysis & trending metrics (what packages were added/removed, size differences, etc). I also think that the nature of our SIG infrastructure doesn't properly encourage the cultivation of sub-communities within Fedora. However, I do plan on trying to help solve some of these problems."
  6. Feedback from Christoph Wickert. "So before I can decide on one of the possible solutions, I'd like to hear a definition of "target audience". I know this is a bit of a chicken and egg problem, but I think at the current state the board should be able to at least say on what level will this audience be defined. Political and theoretical or technical and applied?". Raised the aforementioned system-config-keyboard/anaconda + GNOME deps technical problem.

Conclusion

  • The work performed and the information collected above showed that there were no significant reworks or restatements needed by the Board as a whole. Individual pain points were recognized, and tickets filed for appropriate resolution.