moving to Koji

Stephen John Smoogen smooge at gmail.com
Fri Feb 27 23:25:28 UTC 2009


On Fri, Feb 27, 2009 at 2:25 AM, Thorsten Leemhuis <fedora at leemhuis.info> wrote:
> On 27.02.2009 00:11, Rahul Sundaram wrote:
>>
>> Stephen John Smoogen wrote:
>>
>>> Well I would like to have it that it actually has bodhi votes before
>>> it can be moved. We can have a process for the number of votes needed,
>>> but I would rather have something getting a couple of +1's that can be
>>> tracked than a 1 month timeframe and no one looking at it.
>>
>> You don't have a big enough community for any such process to work well.
>
> I tend to agree.
>
>> EPEL user and contributor base is still small. You should keep things
>> relaxed up atleast until you get a larger base to cover.
>
> Even then I'd say it bureaucracy that is better avoided.
>

Ok the definition of a bureaucracy from wikipedia is:

Bureaucracy is the structure and set of regulations in place to
control activity, usually in large organizations and government. As
opposed to adhocracy, it is represented by standardized procedure
(rule-following) that dictates the execution of most or all processes
within the body, formal division of powers, hierarchy, and
relationships. In practice the interpretation and execution of policy
can lead to informal influence.

My guess is that the group would prefer an adhocracy

Adhocracy is a type of organization being antonymous to bureaucracy.
The term was first popularized in 1970 by Alvin Toffler[1], and has
since become often used in the theory of management of organizations
(particularly online organizations), further developed by academics
such as Henry Mintzberg.

http://en.wikipedia.org/wiki/Adhocracy

 It requires sophisticated and often automated technical systems to
develop and thrive.[1]

Characteristics of an adhocracy:

    * highly organic structure[2]
    * little formalization of behavior[2][1]
    * job specialization based on formal training[2]
    * a tendency to group the specialists in functional units for
housekeeping purposes but to deploy them in small, market-based
project teams to do their work[2]
    * a reliance on liaison devices to encourage mutual adjustment,
the key coordinating mechanism, within and between these teams[2][3]
    * low standardization of procedures, because they stifle innovation[1]
    * roles not clearly defined[1]
    * selective decentralization[1]
    * work organization rests on specialized teams[1]
    * power-shifts to specialized teams
    * horizontal job specialization[3]
    * high cost of communication[3]
    * culture based on democratic and non-bureaucratic work [3]

If that is what people are wanting.. then we will need to show how we
are considering these packages Enterprise ready... otherwise lets get
rid of the pretext of 'stable' and push towards making the tools to
make it work.



-- 
Stephen J Smoogen. -- BSD/GNU/Linux
How far that little candle throws his beams! So shines a good deed
in a naughty world. = Shakespeare. "The Merchant of Venice"




More information about the epel-devel-list mailing list