----- "Kevin Fenzi" <kevin(a)scrye.com> wrote:
>
> I would rephase that as: "who can nominate someone as a #fedora op".
> Should we allow self nominations?
> Should it be only any existing #fedora op?
> Should it be more than one existing #fedora op?
>
> We can add this to the meeting next week...
>
This is a simple effort it would appear to eliminate a few ops from having a voice because I am willing to be a "trouble maker" or "asshole" or "dink" or "troll" or "illogical", these are the names I have been called since this issue and the #fedora users I choose to nominate have come up. I am not sorry that I feel those that are perhaps not the "favorite sons" may be good ops and good to have involved in establishing the ops feedback process. I do not feel that we should be adding ops mid stream of that task, this should not however prevent us from aligning added ops for once that process is complete.
-- Bob
------------------------------------------------------------------------
| Robert 'Bob' Jensen || Fedora Unity Founder |
| bob(a)fedoraunity.org || http://fedoraunity.org/ |
| http://bjensen.fedorapeople.org/ |
| http://blogs.fedoraunity.org/bobjensen |
| http://www.facebook.com/rpjensen |
------------------------------------------------------------------------
Greetings and welcome to the list everyone. ;)
As you know, I have been hoping we could come up with a better way to
allow people to provide us feedback and let us act on it. A pile of
ideas is in:
https://fedoraproject.org/wiki/User:Kevin/Support_Feedback
At our last meeting we decided to setup this mailing list, and also
look at perhaps setting up a trac instance for feedback. I haven't
asked for the trac instance yet, as we aren't sure how we will use it.
So, what do people want to do?
Some possible ideas:
a) Just use this list for feedback. Sadly, that will likely result in
flamewars from people who aren't being constructive and/or people who
aren't taking criticism well. Since this would be public, there might
be ill will from people who air their dirty laundry who regret it
later down the road. We could moderate flamewars, but then we need to
know when to do so.
b) Setup a trac instance for people to file tickets. One advantage of
this is that we could force a template. This could point them to the
FAQ page, note that they should be constructive, ask for specific logs
or other information that people just posting to a list wouldn't
provide a lot of the time and ask them what outcome they are trying to
achieve. We still need to decide who triages the tickets.
c) Something else? Mail alias, moderated list, just keep the current
process as is, etc.
Note that the above are ideas on how to accept feedback, they don't say
anything about how we should process them or act on them.
Thinking about all this stuff makes me really want to go back to as
simple as possible, and when/if that doesn't work, try something else.
So, I would personally propose we just use this mailing list for
feedback, and we all try and accept feedback and come to some some of
rough consensus on how we want to act on it.
kevin
Hello,
We've noticed time and again that some support requests in #fedora
stem from extensive modifications of users' systems. Kernels from
kernel.org, or xorg from git, come to mind. As a result, we seem to
have an informal policy stating that we do not support extensively
modified systems. Yet this policy is not present in the FAQ, and it is
sometimes non-trivial to make sure a user's system is not modified.
To facilitate checking for obvious modifications, I am considering:
* adding a --pretend option to yum, which coupled with
--distribution-synchronization and fpaste, which would enable us to
trivially know whether a system is both up to date and in sync with
what we're shipping at that precise moment.
* creating a script to gather other information, like the version of
both kernel and Xorg, the output of rpm -qVa, and the output of yum
--pretend --distribution-synchronization. This script could be
included in Fedora.
We already ship sosreport in sos.noarch but I think this is overkill
for our use.
As for the FAQ entry, this is my proposal:
== Keep to Fedora-provided packages ==
Please use the packages Fedora provides. Deviating from these can
render your system unstable or introduce bugs. You should exercise
caution before adding software from third-parties, especially
unpackaged software.
I would like us to show openness to modifications though. Two specific examples:
* some users happen to need a kernel, or xorg stuff, from
updates-testing for their hardware to work. Of course this will break
other packages (the kmods from rpmfusion come to mind), but I feel we
can manage such situations, or at the very least explain what could
break when doing that.
* some users request support after breaking their systems, for
instance while installing proprietary drivers with upstream
installers. I don't think we should stop at saying "not supported" in
this case, especially if said user asks how to repair his system
(which is something we can help with most of the time).
Please let me know what you think. Comments and flames both welcome :)
Cheers
François
Here's what I have for an agenda for tomorrow's meeting, which will be
held at 16:00UTC in #fedora-meeting on irc.freenode.net.
Feel free to reply to this with additional topics, or bring them up in
the "open floor" section of the meeting.
#topic Week in review
http://fedora.theglaserfamily.org/ircstats/fedora-weekly.html
#topic Feedback Processes
#topic Fedora 14 Alpha coming up.
#topic Open Floor
kevin