Hi,<br><br><div class="gmail_quote">On Fri, Jan 8, 2010 at 6:14 PM, Graham Cobb <span dir="ltr"><<a href="mailto:g%2B770@cobb.uk.net">g+770@cobb.uk.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im">On Friday 08 January 2010 17:24:22 Valerio Valerio wrote:<br>
> > NOOOO!!!<br>
><br>
> Well the community made a decision, it was discussed during a long period<br>
> of time here and in TMO, don't you think we should respect the community<br>
> decision ?<br>
<br>
</div>I don't think the community made a decision. I think the community has many<br>
different views with nothing having majority support except that users need<br>
an easy way to ignore command line apps. My recollection of the part of the<br>
community that lives on this mailing list was that the preferred option was<br>
the icon/badge and I thought that was what we were working towards.<br></blockquote><div><br>Seems that Andrew is right about brainstorm, will fail miserably again.<br> <br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="im"><br>
> Don't know if I get it, your suggestion is to not change anything ?<br>
<br>
</div>My suggestion is to do four things:<br>
<br>
1) Require all user/ packages which do not install an application icon to use<br>
the community-defined icon or badge to indicate that. Note that this is<br>
nothing to do with whether the UI is GUI or command-line or no UI at all --<br>
it is about whether it installs an application icon and it is intended to<br>
reduce user confusion.<br>
<br>
2) Add a package field to mark the app as command-line so that future user<br>
interfaces can, if they wish, implement controls to allow users to hide<br>
command line apps. Exact mechanism was still TBD but something like debtags<br>
seemed to be favourite.<br>
<br>
3) Enhance HAM to implement the "hide/show command line apps" option (using<br>
the field introduced in 2) to reduce clutter for people who don't want to see<br>
command line apps. This is how I interpreted the meaning of "switcher" in<br>
the brainstorm solution 3 and I would be happy to support that. I am not<br>
happy to support any abuse of the "category" field.<br>
<br>
4) Meanwhile, add popularity and ratings filters to <a href="http://maemo.org" target="_blank">maemo.org</a>, possibly as<br>
part of application karma or possibly separately. And strongly encourage new<br>
users to use <a href="http://maemo.org" target="_blank">maemo.org</a> for finding new applications.<br>
<br>
My personal view is that 4 is the real solution to not just this but many<br>
other QA issues: let the users tell us which apps are good. If we invest the<br>
effort in that we can save a lot of angst about all sorts of arbitrary rules<br>
in QA and get the QA process back to focusing on serious issues like device<br>
stability, etc.<br></blockquote><div><br>Good points, I agree with them, but I'm afraid that with all the stuff happening, we'll not seeing it happening any time soon, since it does not depends entirely on the community. Feel free to carry this task if you want.<br>
<br>Best regards,<br><br>-- <br>Valério Valério<br><br><a href="http://www.valeriovalerio.org">http://www.valeriovalerio.org</a><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="h5"><br>
Graham<br>
_______________________________________________<br>
maemo-developers mailing list<br>
<a href="mailto:maemo-developers@maemo.org">maemo-developers@maemo.org</a><br>
<a href="https://lists.maemo.org/mailman/listinfo/maemo-developers" target="_blank">https://lists.maemo.org/mailman/listinfo/maemo-developers</a><br>
</div></div></blockquote></div><br><br clear="all"><br><br>