Re: [EPEL] EPEL -- the way forward

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Fri, 2007-02-23 at 14:03 -0900, Jeff Spaleta wrote:
> On 2/23/07, Karsten Wade <kwade@xxxxxxxxxx> wrote:
> > The purpose of the job description is to make it easier for people who
> > maintain packages to get at least some of the work "guaranteed" by their
> > employer.  Obviously it is not a guarantee or a contract to support the
> > package.  This is where the wording matters.  It is just about extending
> > the personal responsibility to the organization.  For example, an
> > individual can orphan a package for any reason, and their responsibility
> > is just to announce the orphaning.  The same should hold true for an
> > organization.
> 
> 
> Do you have buy-in or feedback from organizations at the
> organizational level on this approach? From manager-like entities who
> would be making this commitment on behalf of their organization or
> company?

I would think this is something that should be approached at the hiring
manager level, that is, the level where the manager is directly involved
in deciding/defining job descriptions.

> Not to name names or anything..but after FudCon I was on the same
> flight back with dgilmore, and we had a little chat about EPEL and the
> contributor landscape for it.  It was obvious to both of us that IT
> people in smaller organizations would very much be interested
> consumers of this material, but it wasn't clear that they would have
> organizational support to maintain this material as part of their job.
> I think some rather valid observations were made concerning the
> possible reluctance of IT people in a corporate setting to be involved
> in a maintainership role, exactly because it would appear to be an
> additional worktime commitment, not supported by their organizations.

If I read you correctly, you are bringing up the exact reasoning I had
for putting together a generic job description people can use.  My
approach is a first stab; obviously many more of you are experienced
with this.  I may not get paid for my Fedora work, but I have an easier
time justifying my time spent. :)

What approach would you take?  Is this the right one?

Whatever approach this community recommends is probably exactly what
I'll recommend to Red Hat to incorporate.  To make it clear, I think it
is the job of the EL distributor (Red Hat, or CentOS, or whoever) to
help promote joining the EPEL community.  To that end, my goal at Red
Hat is to have a set of materials that "make sense" for ISVs, IHVs, and
customers; then make sure those materials are in the hands of the
marketing, support, and service organizations who have direct contact
with the target audience.  Any help in that direction is (likely) Good
For All.

- Karsten
-- 
Karsten Wade, RHCE, 108 Editor    ^     Fedora Documentation Project 
 Sr. Developer Relations Mgr.     |  fedoraproject.org/wiki/DocsProject
   quaid.108.redhat.com           |          gpg key: AD0E0C41
////////////////////////////////// \\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\\

Attachment: signature.asc
Description: This is a digitally signed message part

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux