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
