<Emad78> How do I know what "branch" to use when editing a doc. Will someone tell me exactly which one to use. <Emad78> Also I can just follow the git wiki commands to do that stuff?
<quaid> here's the basic idea: <quaid> * If the bug is filed against a specific version of a document that ties to a specific version of software, so the bug is only applicable to that version of the document, then we want to fix the bug in the branch associated with that version. <quaid> typically that branc is "F-12" or some such. <quaid> * However, in docs it's common that the bug needs fixing in all versions, so that might mean fixing it in HEAD and then committing the same change in the other branches <quaid> also, we don't support (fix) docs that are tied to a release of Fedora that is no longer supported. <quaid> the git guide on the wiki has most of the commands you need, I think.
<Emad78> Ok, so when I made all those edits on the UG, I made a bunch of changes in 4 files. Is it good to do so many changes and do one commit for all of them? <quaid> it depends :) <quaid> are they all a fix for one bug report? <quaid> if so, one commit is fine <quaid> one per bug report is a good measure <quaid> another example of where to split: <quaid> if you make big structure changes, do those first and commit, then do content changes (clean-up, typos, etc.) as a second commit <quaid> it makes it easier for others to review the work and see the impact. <quaid> one nice thing about git, if you haven't discovered it, is that committing is easy since it's a local event; I find myself committing more often for more granular reasons because it's "cheap" and can be done offline.
- quaid was a CVS and SVN user for many years and dreaded each commit.
<Emad78> Ok, So the proper etiquette is to ask the Doc owner before doing a bug fix then right. Cause there might be a couple fixes I can do to keep on learning> <quaid> it depends :) <quaid> you can put a note in the bug report that you'd like to fix it, or go ahead and show the fix. <quaid> if you've been given commit rights to the doc repository by the doc owner <quaid> you have already been given what you need to make your own decision - if you think you have it (or even may have it), do the fix and commit it. <quaid> you can note in the bug report that you made a commit (link) and think it fixes the bug., if so, please close. <quaid> of course, if you keep doing that, you'll end up with bugs assigned to you :) <quaid> remember -- source control management means never having to say you are sorry <quaid> if your fix doesn't work, it can be backed out, or more likely, just tweaked in the next commit.
<Emad78> I'm usually full of them, so I never know when they pop up. teachingopensource.org <quaid> Emad78: one nice thing about IRC is the asynchronous nature of it <quaid> I leave my client running all the time in a way I can detach from, so if you ask questions or comment <quaid> I see it later and reply <Emad78> Yes this is way easier than emailing a ton to you. <quaid> we have discussions that span timezones and never even be together in the channel at the same time <quaid> right, but it misses some of the value of mailing lists -- it's a balance <Emad78> I hear ya. <quaid> for example, in the mailing list many more get to read the above advice; but it can be inconvenient for every little thing <quaid> anyway, don't be afraid to leave questions in the channel and see who answers :) <quaid> because we are "just like" coding projects, even non-docs team participants might know the right answer, etc. <Emad78> Yeah, and I figured these were pretty easy to answer. And since I was on here I thought I would see if anyone was around.
<quaid> since the textbook I'm working on includes this sort of material, I'll likely reference it to the list later, see if it's useful to newer contributors, etc. <Emad78> Yeah that's true. Maybe if I gather a bunch of new contributor questions I can email the list. You think we could do a new contributor FAQ type thing??
<laubersm> Emad78, you can just start creating one in the wiki ;) <laubersm> Thanks quaid for answering... I'm not really here yet... been busier than I thought for the day <laubersm> and I have a few more things to do before dark. Then one other chapter to review before I can dig into the UG stuff. <laubersm> My *plan* (that is failing miserably so far) was to see what had to be done so I could get a task list going somewhere (trac or wiki depending on what I find) <Emad78> laubersm: I would need some direction in starting something like that on the wiki. <laubersm> Emad78, is doing a great job killin goff the bugs! <laubersm> Emad78, can do - just not for at least another couple of hours. <laubersm> others might be able to help sooner (hint hint quaid) <Emad78> laubersm: Oh no it doesn't have to be right now. But SOON would be good. <laubersm> Emad78, keep making notes. we will eventually get to them.
- laubersm is off to finish other stuff now...
<quaid> Emad78: there's a cultural thing in FLOSS about "annoying newbies", both from the perspective of the experienced contributor and the person who may feel like an annoying newbie! <quaid> https://www.theopensourceway.org/wiki/Stuff_everyone_knows_and_forgets_anyway#Turn_annoying_newbies_in_to_instant_contributors_with_the_power_of_To_Document <quaid> that's what laubersm just did to you :) <quaid> which I was also considering, so I'm happy to help get that flow <quaid> for super-easy you might want to make a page in your personal "sandbox" on the wiki, that is, the pages under your user name: <quaid> User:Emad78/New_Docs_contributor_FAQ_dump <quaid> then copy and paste our discussion from above in to there as a quick grab and reminder :) <quaid> you can actually construct the whole thing there, then 'move' it later to Docs new contributor FAQ <Emad78> Well ok then, on to being a "contributor" then. Thanks laubersm ;) <Emad78> quaid: This (theopensourceway.org) is a good read.