|
|
| (107 intermediate revisions by the same user not shown) |
| Line 1: |
Line 1: |
| <Emad78> How do I know what "branch" to use when editing a doc. Will someone tell me exactly which one to use.
| | {{Draft}} |
| <Emad78> Also I can just follow the git wiki commands to do that stuff?
| |
| <quaid> which guide?
| |
| <quaid> here's the basic idea:
| |
| <Emad78> Any I guess? Just curious.
| |
| <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 somesuch
| |
| <quaid> * However ...
| |
| * kishan has quit (Remote host closed the connection)
| |
| <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.
| |
| <Emad78> Ok, I see, I see, cool.
| |
| <quaid> the git guide on the wiki has most of the commands you need, I think.
| |
| <quaid> Emad78: ok, how much of what I said made sense and how much gobldiguk?
| |
| <Emad78> No that makes sense. That's good. I've been having a blast doing this the last couple weeks. Just trying to gather as much info as I can.
| |
| <quaid> word
| |
| <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.
| |
| <Emad78> Ok, perfect. That answers it. :)
| |
| <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> That's what I heard, it was WAY slow.
| |
| <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 has a favorite phrase today!
| |
| <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> Ok cool.
| |
| <Emad78> quaid: I think those were all of them. The easy questions.
| |
| <Emad78> quaid: Thanks a bunch
| |
| <quaid> rocking, you are most welcome
| |
| <Emad78> I'm usually full of them, so I never know when they pop up.
| |
| * quaid is working on a document today, as it happens, with all the same tools, but for 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> makes sense
| |
| <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. I would have read this earlier if I knew where to find it. :)
| |
| <quaid> ;-D
| |
| <quaid> Emad78: spread the word :)
| |
