No more right click terminal

[Jeff Spaleta]

On 7/15/05, Toshio Kuratomi <toshio at tiki-lounge.com> wrote:
> I'm prepared to accept that.  Don't think I'm prepared to support it
> though.  These are ideas to encourage people about the community aspect
> of Fedora.  Is banning people something that supports or discourages
> community?  

You said everyone needs to agree on respecting a boilerplate offtopic
post.  If people are expected to respect that boilerplate and stop
posting.. then i think its perfectly reasonable to espect that people
who dont respect that boilerplate response to be warned and if they
are habitual abusers asked to leave because they have disrespected
established agreed apun rules of conduct for the list.  If the
boilerplate offtopic response can't be relied on to move the
discussion... I don't see the point really in creating or using that
boilerplate response.


> I think the first impression will be similar to the
> -maintainers first impression.  Could even be worse unless we set up a
> parallel fedora-devel-readonly list.  And what about redhat personnel?

moderation for fedora-devel has been suggested repeatedly to me and in
the past i have always fought against it. At this point I frankly
don't care to fight the suggestion any longer. Now that maintainers is
open as a tool for contributors, the -devel list has lost much of its
relevancy as a useful tool among contributors... I'm no longer going
to make the effort to encourage better signal to noise here.  From now
on, I'm just looking for ideas I agree with and will help make sure
those ideas make it to the right people.
 
> One of the original Fedora openness requirements was that discussion was
> to take place on the fedora-devel list.  Can they be banned?

Acceptable use policies can still apply to open lists. If everyone
participating is suppose to agree to respect the boilerplate response
you proposed that I think its perfectly reasonable to enforce that
agreement on pain of death.

> I think banning people is somewhat of a different topic.

Shrug, feel free to create the boilerplate and use it as you see fit.
I fully expect certain people to ignore the boilerplate and to
continue to discuss the material you deemed as off topic.

> Sabayon certainly looks like it could be a more directed approach.  The
> question I have, though, is whether Sabayon will let me ship a config to
> Jesse, or Matthias to me.  In other words, not just from
> system-administrator to user, but user to user.

I have no idea.

> The area I'm thinking needs to be filled is preference-themes.
> Developers need a developer-oriented desktop.  Mom needs a
> point-and-click oriented desktop.  Graphics designers need a
> let-me-learn-as-I-work desktop.  Can Sabayon be used to create a
> pre-cooked file that the end-user can download and install to utilize
> the preferences they think are right?

I think thats sort of the idea.... to have different user profiles for
an admin to use. The admin applies one of the N user profiles via
sabayon to one of M users. N!=M.

> Right now, I'm just brainstorming.  I identified a problem.  These are
> some possible solutions.  Do you agree that the problem exists?  Do you
> have an alternate off-the-wall solution?

Right now, my best understanding is that sabayon is meant to fill this
niche on simplifying how to move a user from defaults to one of a
number of different profile configurations. I don't know if you can
easily pull in sabayon profile definitions from one box to another..
or what it would take to pre-package a profile in an rpm in extras. 
Something to talk to the sabayon developers about.  It certaintly
seems like there should be a way to easily trade sabayon profiles
across machines.

-jef"sabayon profiles.. collect them all!"spaleta