minutes/log 26-Apr-2005 meeting

[Karsten Wade]

<megacoder> Call the meeting to order, it's past time.
* quaid kicks megacoder in the grumpiness
<quaid> hear ye, hear ye, etc.
<quaid> <meeting>
<stickster> OK... CVS access rules?
* quaid is disorganized
<quaid> yes
* stickster has your back, man
<quaid> has everyone had a chance to glance over the CVS access rules?
<megacoder> I particularly liked the part about withdrawal without
prejudice.
<elliss> Ta.
<elliss> Sounds a bit legal
<stickster> megacoder: Isn't that the charter you're talking about?
<quaid> http://www.fedoraproject.org/wiki/DocsProject_2fCvsUsage
<megacoder> Naw, look at "Process Flow" about the middle
<elliss> I put it in
<stickster> elliss: Oh yeah, sorry, I remember reading this earlier
<elliss> If anybody can think of a better phrase than "without
prejudice" that would be cool
<quaid> seems like a good word to me
<megacoder> "without extreme prejudice"?
<stickster> elliss: It's fine
<quaid> megacoder: this is not a CIA workflow :)
<megacoder> No, really, it's great as it is.
<quaid> stickster: are you happy with this as a draft for full comments,
changes, then acceptance?
<stickster> I think so. Thanks, Stuart, for the additional bits!
<stickster> Keep in mind this creates a need for ACLs on the CVS... is
that within our ken?
<quaid> theoretically
<quaid> we can work it out and will learn as we go
<quaid> who else wants to help maintain the CVS administratively?
<quaid> just to divide the work, that is
<stickster> I wouldn't mind, if my name's not in the hat
<stickster> I didn't know if writing the doc implied that
<quaid> why I asked :)
<quaid> for our own purposes, we'll need to capture the process how-to
get someone ACLs correctly, etc.
<stickster> *nod
<stickster> Is it within scope to address our pending request(s)?  Only
1 that I know of
<quaid> ok, I move to accept the CVSUsage guidelines
<megacoder> seconded
<quaid> stickster: I was going to email that fella, but since he's not
personally clamoring, I decided to wait a day or so and just send an
announcement to the list of the process.
<stickster> quaid: great, my thinking exactly
<megacoder> Refresh my memory: how did he get into the list, anyway?
<stickster> All in favor?
<quaid> or the other way
<megacoder> aye
<elliss> Not quite
<quaid> any opposed?
<stickster> aye
<quaid> elliss: go ahead
<quaid> megacoder: signed himself up for access :)
<elliss> How do we kick someone off CVS (or let them resign) ?
<megacoder> That's what I get for being asleep most of the time.
<quaid> stickster: when you get the chance, you can fix/ammend/remove
your comments in the Wiki page.
<quaid> elliss: interesting question
<Sopwith> elliss: They can remove themselves from the group in the
account system
<Sopwith> Or the administrator can remove them.
<quaid> elliss: are you also thinking of the process?
<quaid> i.e., the rules?
<elliss> Yes.
<quaid> will it help people to know what is an infraction?
<stickster> stickster: OK
<stickster> quaid: OK
<elliss> We don't want to seem arbitrary
<Sopwith> FWIW Greg and I were talking about a similar policy for extras
<megacoder> Do we just remove names from the ACL's but leave the
account?
<quaid> or remove the account and clean up the ACLS later?
<Sopwith> Generally, ACL's aren't really needed at all except to control
access to high-risk stuff like the CVSROOT or the web site.
<quaid> about ACLS
<quaid> my thinking was, honor system 
<stickster> There's nothing about ACL's in the "cvs usage" page, I
believe... that was on purpose
<quaid> tell people not mess around in other locations, rather then
force them not to.
<stickster> "Access" was more of a logical construct
<elliss> For us ACLs are really to protect the contributor themselves  
<megacoder> I would think that de-acling documents would be sort of a
hand-slap.
<Sopwith> When I helped with Gnome CVS, we had no ACLs at all on
hundreds of modules with thousands of people. The best way to make sure
people do the right thing is to hold them accountable by reading fedora-
docs-commits list.
<tcf> hi everyone, sorry I'm late
<megacoder> You'd have to beg to get back onto it.
<tcf> got stuck in another meeting
<quaid> tcf: s'alright, we're talking about CVS
<quaid> megacoder: easier to disable their entire account :)
<elliss> Sopwith: Our contributors aren't necessarily developers, so may
have no experience at all with CVS
<Sopwith> If someone is really causing problems, it'll be very apparent
to you guys what action to take as it happens.
<megacoder> Then an infraction would need to be really bad.
<stickster> Yes, access need not be based on ACLs, since that does
create more of an admin burden anyway
<quaid> yep
<stickster> Infraction: something that messes up someone else's work
without permission
<Sopwith> For Extras, the main you-will-lose-your-account infractions
are cracking and putting illegal material in CVS
<quaid> elliss: I think they will be more cautious, then, and less
likely to mess around other places.
<megacoder> OK, OK, that's why we get paid the big bucks to be on the
Steering Committee, but is there any legal risk if someone gets P/O'ed?
<quaid> stickster: amend that with, "intentionally"
<stickster> quaid: oh yes, thanks
<Sopwith> megacoder: No, PR risk is the main worry I believe.
<stickster> megacoder: It's a volunteer project after all
<quaid> how about:
<megacoder> I'm don't mean about the content, but if someone gets
banned ...
<quaid> no admin ACLs unless critical
<megacoder> they could take it ill.
<elliss> I'm most worried about small unrecorded changes, done for good
intensions
<quaid> elliss: won't be unrecorded
<stickster> elliss: All changes go to a commits list
<elliss> OK - I know nothing about CVS
<stickster> megacoder: because it's not a public space, there's no
guarantee of access for anyone -- just like a business reserves the
right to eject you, even though you can then picket them from outside
<Sopwith> elliss: CVS keeps track of all changes, so if someone goofs up
(intentionally or not) it's very easy to go back to the previous version
of a file.
<elliss> OK.
<tcf> quaid: I don't think we can implement acls right now anyway
<Sopwith> It's not so important to come up with enforcement mechanisms
and consequences right now, as to make the rules of the road clear to
all. When problems come up, you will figure out the best way to deal
with the situation.
<elliss> I guess public embarrassment is a good control
<megacoder> Well, I'd be happer with a Webbick pronouncement about
booting folk.
<quaid> s/ick/ink/
<tcf> I talked to gdk about cvs access this afternoon, and he said for
extras, you get access if you ask and if you do something bad, they
revert the changes and that person is banned
<tcf> make it simple is the rule
<stickster> Sopwith: Extras will maybe have a policy on this soonish,
right?
* quaid has a proposal:
<quaid> * No admin ACLs unless a critical item (i.e., website, CVSROOT)
<quaid> * Social access control
<quaid> * No cracking, no illegal materials (bad breach)
<quaid> * No intentional meaneness (minor breach)
<quaid> * Be careful, ask first (low breach)
<stickster> quaid: Add doc guide to that maybe
<quaid> stickster: ok
<quaid> agreed
<megacoder> suits me.
<stickster> ditto
<quaid> stickster: do you want to add those guidelines, clean up your
comments, and it's ready for a first itreation?
<megacoder> Keep in the part where we get to shoot'em in the back,
though.
<quaid> word
<stickster> quaid: yes
<stickster> True dat
<quaid> "You wouldn't shoot an unarmed man in the back, would you?"
"I've done worse."
<elliss> He had glasses on
<quaid> ok, as a finish to this item
<quaid> fedora-docs-commits should be ready right after this meeting,
I'll fix up the final details with Sopwith 
<quaid> go ahead an subscribe, and I'll make an announcement to the list
about CVS that covers:  general philosophy, link to access rules, link
to commits list
<quaid> anything else on this?
<quaid> ok
<quaid> Master Tasks ...
<quaid> small agenda item, this
<quaid> I threw it in case there was a status about it, but it's a work
in progress.
<quaid> http://www.fedoraproject.org/wiki/DocsProject_2fMasterTasks
<stickster> status about the list, or status on items thereon?
<quaid> about the list
<stickster> k
<quaid> seeing if anyone had anything to add, questions about items on
it, etc.
<quaid> moving along ...
<quaid> passing on item 3, the process docs for FDSC
* quaid looks to see where we are at with assigning editors process
<stickster> What do we have in process right now without an editor?
<quaid> one thing we have is several docs _I'm_ editing that I might
like to pass on :)
<quaid> good point, though
<quaid> we can table this until we actually have a problem a process
would solve :)
<stickster> You can pass them on as soon as the Style stuff is in the DG
for others to refer to...
<quaid> true!
<stickster> Ha-HA!
<quaid> very nice and subtle point :)
<elliss> Do we have a true master list of docs ? 
<stickster> There is https://bugzilla.redhat.com/bugzilla/show_bug.cgi?
id=129807
<elliss> Mmm
<stickster> The docs-in-progress tracker bug... I think we've been
pretty good about keeping it updated
<stickster> We may need to prune
<elliss> Does anybody know anything that's not there ? 
<stickster> Maybe someone would like to take the task of gathering
status and circulating a report before next FDSCo meeting
<stickster> maybe including "lost docs"?
<tcf> yes, we definitely need to go through the list and nudge people
<elliss> I'll build the Wiki page
<stickster> For instance, Charles ("tuxxer") just picked up one that was
stagnating in my pile
* stickster hides head in shame
<tcf> I used to do this, and about 75% either didn't respond or said
they hadn't done anything
<tcf> it is important to keep the list fresh
<tcf> elliss: build a wiki page to list all the docs in progress?
<stickster> tcf: absolutely..... hi, by the way :-)
<tcf> stickster: howdy ;-)
<elliss> Yes. I said I'd maintain it
<elliss> I'll go through the bug
<quaid> all right, you got it
<tcf> ok
<quaid> https://bugzilla.redhat.com/bugzilla/showdependencytree.cgi?
id=129807
<tcf> I was going to volunteer, but elliss is too quick ;-)
<quaid> check out the dependency tree for a nice view :)
<stickster> tcf: Back on your head, we're waiting for issue 7
<quaid> moving on to 4. Process improvements for FDP
<tcf> stickster: hehe, it should be out in the middle of the month as
usual ;-)
<quaid> my report is that I haven't changed anything or updated
anything, but there has been some thinking going on.
<tcf> what processes are still not finalized?
<quaid> what I need to do is tie together the disparate pieces into the
Doc Guide
<megacoder> Could you send us a context diff?
<quaid> tcf: mainly a sanity and consistency check, since we have
process stuff all over the place
<quaid> megacoder: what?  of my life?
<stickster> Do you think you'll ultimately add that thinking into the
DocGuide v2 outline?
<quaid> that's probably a good place for it
<stickster> I was thinking the same thing while I was making the
outline... it was difficult to find everything at times
<quaid> you found quite a bit :)
<quaid> but yeah, that's the point of putting everyhtiing in the canon
<stickster> Right
<quaid> ok, I'll follow up with a report on the FDP website 
<quaid> I've had some good suggestions and did a few changes, a few more
are needed.
<quaid> it would be good for someone else (besides tcf) to understand
how the website works
<quaid> one reason why is
<quaid> FESCO has asked if we can help with updating the entire website
<quaid> in terms of content
<quaid> so, I'm bringing that here for discussion ...
<stickster> It would kind of make sense... keep the writing/editing with
the writers/editors
<tcf> sounds like we need a website team
<quaid> personally, I'd like to see project leaders do real updates, and
let us edit them ... but ...
<tcf> to maintain consistent formatting, page locations, etc.
<quaid> one of gregdek's points is that many "projects" aren't, and many
that are projects aren't on the site.
<quaid> tcf: yes
<quaid> we can recruit for more help from the list
<tcf> maybe the first step is to write up a quick and simple list of
rules to use when building pages
<stickster> quaid: Which means that we need reference for people
performing that task so they can do it correctly and consistently
<quaid> jinx!
<elliss> Is the technical side being revamped ?
<tcf> I like quaid's idea of just being the editors
* quaid looks at tcf about revamping?
<tcf> not sure what the status is
<stickster> Just editing sounds like a big enough bite for now
<tcf> I'll ask gdk when he gets back to his desk
* stickster agrees with tcf
<quaid> yeah, me too
<elliss> OK.  It affects the content req'd
<quaid> tcf: can you write up an expansion of your website howto pages?
<quaid> something we can put in the Doc Guide and point all project
leaders at?
<tcf> for modifying the website on fedora.redhat.com?
<quaid> yes
<tcf> sure, but I think we need to know whether we are moving to
fedoraproject.org and wiki or to HTML only in cvs for fedora.redhat.com
<stickster> quaid: I like this idea... makes me think of another
organizing factor, where each chapter will indicate clearly at the front
whom it concerns
<quaid> something that includes quick/simple list of rules for building
pages, and links to parts of the Doc Guide and other places that tell
how to make things consistent.
<tcf> last time I talked to gdk about it, he had a prototype of
fedora.redhat.com in html with ssi instead of all the php stuff
<quaid> tcf: good point
<quaid> ok, let's get a status on that before we put more time into the
rest of f.r.c
<tcf> let me ask gdk about it first and if the word is that we are stuck
with php for a while, then I'll write it up
<stickster> What is the effect of the ssi change?
<tcf> if the word is that we are going to html or wiki soon, I'll make
it more generic
<stickster> Sorry, don't do live websites where I work :-)
<tcf> php allows you to have "php templates," variables like with a
programming lang, and scripts that part content and generate html
<stickster> Right... I use that on my own blog
<stickster> SSI is server side includes, yes?
<tcf> yes
<tcf> so with ssi you can do simple things like have one header or
footer fiile
<tcf> file
<tcf> and have an include line to bring it into all pages that need to
share that content
<tcf> same concept as the /common dir in fedora-docs
<stickster> Oh, OK, I think I see... I do this with cheap-o javascript
includes on another site I have at home for my HOA... same idea?
<tcf> need it more than once, write it once, update it once, etc.
<tcf> stickster: sounds like it
<stickster> tcf: Thanks  :-)
<tcf> ssi=cheap content management ;-)
<quaid> ok, I'll continue maintaining our own pages
<quaid> we should think about one of us leading a website team of
editors from within the FDP
<quaid> and that will help with the rest of f.r.c
<tcf> agreed
<elliss> If you can point me at the source I'll can submit patches for
our page 
<quaid>  /cvs/fedora/web
<elliss> Thanks.
<stickster> In fact, that's probably the easiest way for you to accept
changes, right quaid?
<quaid> yes
<quaid> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=155642
<quaid> attached to that bug
<quaid> ok, we're in the "misc/open" part of the agenda
<tcf> I think a priority 1 for f.r.c is updating the CVS chapter
<quaid> or continued discussion, or you can just leave if you want
<tcf> is someone assigned to that yet?
<G2> I am watching.... ;-)
<quaid> don't think so
<tcf> want me to take a crack at it?
<stickster> quaid posted some changes but they look kinda funny since he
was stuck with the bottom piece
<tcf> stuck with the bottom piece?
<stickster> tcf: Oops, you meant the DocGuide, didn't you?
* tcf doesn't understand
<tcf> stickster: yes
<stickster> Sorry, I was talking about the simple CVS page
<stickster> In with the "participate" stuff
<megacoder> Hey, we just got a web site maintance voluteer via self-
intro...
<quaid> cool
<stickster> Eric R?
<megacoder> yup
<stickster> Like he doesn't have enough to do with FLP!  Glutton for
punishment, he is...
<megacoder> Then should we question his judgement ;-?
<tcf> stickster: do you have a link?
<quaid> nah, he works for academia
<quaid> they have time
<stickster> ;-D
<quaid> tcf: I think the answer to your question is, stickster is de
facto assigned to updating the CVS chapter in the Doc Guide
<quaid> but it's not a specific assignment.
<tcf> quaid: ah, ok
* stickster whistles nonchalantly and--- D'oh!!!
<quaid> the changes to the Doc Guide look like a little much for a
single person to handle, unless you have a lot of time.
<megacoder> I'm subscribed to the commit-list w/o any problems.
<tcf> stickster: if you want to update that part, that's fine
<tcf> just trying to volunteer for something
<stickster> tcf: No, I meant that quaid snagged me when I thought I was
getting free help!
<quaid> stickster: can you divide up the changes into chunks and start
with f-docs-list for volunteers?  You can request patches instead of
direct CVS access, because of the special nature of the work
<stickster> quaid: Right
<stickster> quaid: and "yes."
* quaid points at tcf, stickster's first volunteer
<stickster> Woo-hoo!!
<tcf> yep, just let me know what pieces you want me to update
<quaid> all right, who's Dusty Fog?
<tcf> small chunks are preferred
<stickster> tcf: http://fedora.redhat.com/projects/docs/ is the page
with 2 different CVS instruction sets
<quaid> oh, yeah, that!
<elliss> That's really why I asked about patches :)
<quaid> I didn't want to mess with the include structure
<tcf> stickster: right, and
http://fedora.redhat.com/participate/documentation-guide/s1-cvs-
configure.html
<tcf> quaid: is that php magic getting that to show up?
<stickster> tcf: Right, that's what you were referring to, correct? I
don't want the bigger Doc Guide project to block that
<tcf> quaid: I can probably fix that
<quaid> tcf: yeah, the problem is that the include references
rhlinux.redhat.com, which is still true for the main repository but not
Extras or Docs
<quaid> and that's included for the page automagiclaly
<tcf> I see 3 places within Projects -> Docs to update for CVS info:
http://fedora.redhat.com/participate/documentation-guide/s1-cvs-
configure.html and 2 places on http://fedora.redhat.com/projects/docs/
<tcf> quaid: I can fix the PHP to give the right location
<quaid> right, the Doc Guide needs to explain about real CVS usage as
per the CVSAccess rules
<quaid> tcf: but then it will be wrong for other projecs, no?
<tcf> and then stickster can be in charge of picking someone to fix it
in the Docs Guide
<tcf> quaid: not if I create another function name
<stickster> bingo!
<-- Sopwith has quit ("Leaving")
<quaid> tcf: that would be a good transition step, thanks, please do
that and let sopwith and gregdek  know about it so they can give the new
function name to other projects when they move to the new CVS
<tcf> quaid: ok, will do
* tcf writes it down
<stickster> tcf: If you are willing + able, you could do the existing
Doc Guide if you don't mind...?
<stickster> tcf: Excuse me, let me be less vague:
<stickster> If you don't mind, would you be able to fix the existing CVS
*commands* in the Doc Guide? As you said, I'll find someone to do the
larger narrative part
<tcf> sure, I'll update the "Configuring CVS on Your System" section
<stickster> That's the one!
<megacoder> Ach!  Don't edit ~/.bashrc for a one-time change!  Use the
"-d http:..." switch.
<megacoder> You only need it for a one-time login and then once to
checkout a new document.
<stickster> megacoder: Yo man, bugzilla that
<megacoder> I'm stupid today ("what's different?"). Point me to
details..
<quaid> </meeting>
-- 
Karsten Wade, RHCE * Sr. Tech Writer * http://people.redhat.com/kwade/
gpg fingerprint:  2680 DBFD D968 3141 0115    5F1B D992 0E06 AD0E 0C41   
                       Red Hat SELinux Guide
http://www.redhat.com/docs/manuals/enterprise/RHEL-4-Manual/selinux-guide/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-dsco-list/attachments/20050426/b2d8eea7/attachment.sig>