GitHub برای معلمان زبان انگلیسی

آیا ابزار کدنویس می تواند به افراد غیر کدنویس کمک کند تا نحوه نوشتن و ویرایش نثر را بیاموزند؟ GitHub روشی قدرتمند برای ضبط و «بازپخش» ویرایش‌ها به صورت گام به گام، حتی زمانی که متن کد نیست.

در “GitHub برای بقیه ما” من استدلال کردم که ابرقدرت‌های GitHub می‌توانند به همه خدمت کنند، نه فقط به کدنویس‌ها. از آن زمان (۲۰۱۵) من احساس می کردم که در مورد قضیه اغراق کردم. GitHub ابزاری بود و باقی می ماند که عمیقاً برای برنامه نویسانی که کد منبع نسخه شده را ایجاد و بررسی می کنند بهینه شده است. استفاده‌های دیگر ممکن است اما ناخوشایند است، و ابزارهایی که فکر می‌کردم می‌توانند GitHub را برای غیر کدنویس‌ها دوستانه‌تر کنند، عمدتاً وارد نشده‌اند.

اما اخیراً در حال بررسی کارهایی هستم که GitHub می‌تواند برای غیر کدنویس‌ها انجام دهد. همانطور که به همکاران کمک کرده‌ام تا پست‌های وبلاگ و اسناد را بنویسند، به فرآیند ویرایش خود فکر کرده‌ام و به ابزارهایی دست یافته‌ام که می‌توانند به من کمک کنند تا اصولی را که آن را هدایت می‌کنند، بیان کنم.

من مدت‌هاست ابزاری را تصور می‌کردم که معلم را قادر می‌سازد تا به دانش‌آموزان در یادگیری نحوه نوشتن و ویرایش کمک کند. در «افکار در حرکت» آنچه ممکن است امکان پذیر باشد را بررسی کردم در ویکی فدرال، ابزاری برای نوشتن که تاریخچه نسخه را برای هر پاراگراف نگه می‌دارد. فکر می‌کردم می‌توان آن را برای فعال کردن نوع ویرایش آموزشی که در ذهن دارم گسترش داد، اما هنوز راهی پیدا نکرده‌ام.

اخیراً، در “چگونه یک بیانیه مطبوعاتی بنویسیم” من سعی کردم Google Docs را به این منظور خم کنم. برای روایت روند ویرایش یک بیانیه مطبوعاتی، یک نسخه نمونه را در یک GDoc انداختم و مجموعه‌ای از ویرایش‌ها را به عنوان نسخه‌های نام‌گذاری شده ثبت کردم. سپس نسخه‌ها را به‌عنوان اسکرین‌شات گرفتم و آن‌ها را با روایت ترکیب کردم، بنابراین خواننده پست وبلاگ می‌تواند هر ویرایش را به‌عنوان یک تفاوت با کد رنگی همراه با توضیح ببیند.

فعال‌کننده کلید File -> تاریخچه نسخه -> نام نسخه فعلی به همراه File -> مشاهده تاریخچه نسخه ناوبری مبتنی بر کلیک مجموعه است. از تفاوت ها به راحتی می توان از این طریق دنباله ای از مراحل ویرایش را ثبت کرد.

اما ارائه این مراحل مانند من در پست بسیار سخت تر است. برای این کار لازم بود مجموعه ای از تصاویر را بسازم، نام ببرم و سازماندهی کنم، سپس آنها را به تکه هایی از روایت پیوند دهم. کار خسته کننده ای است و اگر می خواهید چیزی شبیه به این برای دانش آموزان بسازید، این کاری است که نباید انجام دهید. شما فقط می خواهید ویرایش ها را انجام دهید، آنها را روایت کنید و نتیجه را به اشتراک بگذارید.

چرا ردیابی تغییرات داخلی در GDoc (یا معادل آن در Word) نیاز را برآورده نمی کند؟ در آن حالت‌ها، تغییرات و تفسیر به ترتیب سند ظاهر می‌شوند. اما روند ویرایش به این صورت اتفاق نمی افتد. برای مثال، هنگام ویرایش آن نمونه مطبوعاتی، عنوان را در مرحله ۱ اصلاح کردم و دلیل خود را در آنجا توضیح دادم. سپس در مرحله بعد، هنگام ویرایش پاراگراف سوم، دیدم که خواستار تجدید نظر در عنوان است. بنابراین من تغییر دیگری در تیتر ایجاد کردم و دوباره دلیل آن را توضیح دادم. ارائه‌ای که من برای پست وبلاگ ساخته‌ام، این توالی را حفظ می‌کند، و فکر می‌کنم این مهم است. ویرایش‌ها لزوماً به ترتیب سند از بالا به پایین اتفاق نمی‌افتند و روایت آنها نیز نباید اینطور باشد. روایت باید داستان را همانطور که در واقع اتفاق می‌افتد بیان کند: حرکت در سند، چندین بار بازدید مجدد از یک قسمت به دلایل مختلف.

اخیراً یک جایگزین مبتنی بر GitHub برای آن تکنیک GDoc امتحان کردم. باز هم هدف نه تنها تولید نسخه ویرایش شده، بلکه روایت ویرایش ها به شیوه آموزشی بود. من سند اصلی را در یک مخزن قرار دادم، ویرایش های گام به گام را در یک شاخه انجام دادم و یک درخواست کشش ایجاد کردم. سپس توانستیم درخواست کشش را بررسی کنیم، تغییرات را طی کنیم و هر کدام را به عنوان یک تفاوت رنگی با توضیح بررسی کنیم. هیچ اسکرین شاتی نباید ساخته شود، نامگذاری شود، سازماندهی شود، یا به روایت پیوند داده شود. می‌توانستم تمام تمرکزم را روی انجام و روایت ویرایش‌ها متمرکز کنم. عالی!

خب، برای کسی مثل من که هر روز از GitHub استفاده می کند، عالی است. اگر شما نیستید، آیا این تکنیک احتمالاً کار می کند؟ بیایید نمونه Google Docs خود را در GitHub بازسازی کنیم و ببینیم چگونه پیش می‌رود. وانمود کنید که یک کدنویس نیستید، هرگز از GitHub استفاده نکرده اید، و چیزی در مورد شاخه ها یا commit ها یا درخواست های کششی نمی دانید (یا می خواهید بدانید). اما شما دوست دارید که بتوانید ارائه‌ای ایجاد کنید که زبان آموز را با توالی از ویرایش‌ها، با روایت گام به گام و تفاوت‌های رنگی هدایت کند. در پایان این آموزش خواهید دانست که چگونه این کار را انجام دهید. من دستور پخت را به دقت شرح می دهم تا بتوانید خودتان آن را امتحان کنید و تصمیم بگیرید که آیا عملی است یا خیر. یا بهتر است از دوستی که معلم زبان انگلیسی است بخواهید این آزمایش را انجام دهد!

این اسکرین‌کست نتیجه نهایی تکنیکی را که من توضیح می‌دهم نشان می‌دهد. می‌بینید که در بررسی یک درخواست جذب GitHub، روی «بعدی» کلیک می‌کنم تا دنباله‌ای از ویرایش‌های روایت شده را طی کنم.

اگر می‌خواهید آن را تکرار کنید و قبلاً یک حساب GitHub ندارید، اکنون یکی ایجاد کنید و وارد شوید.

آماده رفتن هستید؟ خوب، بیایید شروع کنیم.

مرحله ۱: یک مخزن ایجاد کنید

دکمه + را در گوشه بالا سمت راست کلیک کنید، سپس روی مخزن جدید کلیک کنید.

صفحه بعدی اینجاست. تنها کاری که باید در اینجا انجام دهید این است که مخزن را نامگذاری کنید، به عنوان مثال. ویرایش گام به گام، سپس روی ایجاد مخزن کلیک کنید. من کادر افزودن یک فایل README را علامت زده‌ام و مجوز Apache 2.0 را انتخاب کرده‌ام، اما می‌توانید پیش‌فرض‌ها را علامت نگذارید – کادر مجوز هیچ‌کدام – را رها کنید زیرا هیچ کدام برای هدف ما در اینجا مهم نیستند.

مرحله ۲: یک فایل جدید ایجاد کنید

در صفحه اصلی GitHub خود، روی برگه Repositories کلیک کنید. مخزن جدید شما ابتدا نمایش داده می شود. روی پیوند آن کلیک کنید تا باز شود، سپس روی منوی کشویی افزودن فایل کلیک کنید.

مرحله ۳: یک شعبه جدید ایجاد کنید، تغییر را انجام دهید و یک درخواست کشش ایجاد کنید

آنچه در صفحه بعدی اتفاق می‌افتد گیج‌کننده است، اما من شما را از جزئیات صرف نظر می‌کنم، زیرا فرض می‌کنم شما نمی‌خواهید در مورد شاخه‌ها یا commit‌ها یا درخواست‌های کششی بدانید، فقط می‌خواهید نوع ارائه‌ای را بسازید. قول دادی میتونی بنابراین، فقط این دستور العمل را دنبال کنید.

• فایل را نامگذاری کنید (به عنوان مثال sample-press-release.txt
• متن را برای مرور در کادر ویرایش کپی/پیست کنید
• را انتخاب کنید یک شعبه جدید برای این commit ایجاد کنید و درخواست کشش را شروع کنید
• نام شعبه (به عنوان مثال ویرایش‌ها)
• روی پیشنهاد فایل جدید

کلیک کنید

در صفحه بعدی، درخواست کشش را عنوان کنید (به عنوان مثال ویرایش بیانیه مطبوعاتی) و روی ایجاد درخواست کشش کلیک کنید.

مرحله ۴: به شعبه جدید مراجعه کرده و ویرایش را شروع کنید

در صفحه اصلی مخزن خود، از منوی کشویی main برای باز کردن لیست شعب استفاده کنید. اکنون دو مورد وجود دارد: اصلی و ویرایش. ویرایش‌ها را انتخاب کنید.DG

در صفحه بعدی، تأیید کنید که در شاخه ویرایش‌ها هستید.

برای باز کردن نام سندی که ایجاد کرده‌اید (به عنوان مثال sample-press-release.txt) کلیک کنید.

روی منوی کشویی نماد مداد کلیک کنید و ویرایش این فایل را انتخاب کنید.

اولین ویرایش خود را انجام داده و پیش نمایش آن را مشاهده کنید. در اینجا، این بازنویسی اولیه من از عنوان است. من یک عنوان برای commit نوشته ام (مرحله ۱: اصلاح عنوان)، و توضیح مفصلی را در کادر زیر عنوان اضافه کرده ام. می‌توانید تفاوت رنگ‌بندی‌شده را در بالا، و دلیل تغییر را در زیر ببینید.

روی تعهد تغییرات کلیک کنید و برای انجام تغییر بعدی به ویرایشگر بازگشته اید.

مرحله ۵: برای بررسی تغییر به درخواست کشش مراجعه کنید

در صفحه اصلی مخزن خود (به عنوان مثال https://github.com/judell/editing-step-by-step)، روی دکمه کشش درخواست‌ها کلیک کنید. شما اینجا فرود خواهید آمد.

برای باز کردن نام درخواست کشش (به عنوان مثال ویرایش بیانیه مطبوعاتی) کلیک کنید. در سمت راست ترین ستون، پیوندهایی با برچسب های الفبایی را مشاهده خواهید کرد.

اولین موردی را که در اینجا فرود می آید، کلیک کنید.

این اولین commit است که متن اصلی را اضافه کرده است. اکنون برای بررسی اولین تغییر روی بعدی کلیک کنید.

در نهایت، این اثری است که می‌خواهیم ایجاد کنیم: یک ویرایش دانه‌بندی، با توضیح و یک تفاوت رنگ‌بندی شده، که در یک پیوند که می‌توانید به زبان‌آموزی بدهید که می‌تواند روی بعدی کلیک کند تا یک سری از روایت‌ها را طی کند. ویرایش می کند.

کف کنید، بشویید، تکرار کنید

برای ادامه ساختن ارائه، مرحله ۴ (بالا) را یک بار در هر ویرایش تکرار کنید. من اکنون این کار را انجام می دهم.

… زمان می گذرد …

باشه، انجام شد. اینجا نهایی نسخه ویرایش شده است. . برای گذر از ویرایش‌ها، اینجا شروع کنید و از دکمه بعدی برای پیشبرد مرحله به مرحله استفاده کنید.

اگر این یک پروژه نرم افزاری بود، باید شاخه edits را در شاخه main ادغام کنید و درخواست کشش را ببندید. اما لازم نیست نگران هیچ یک از این موارد باشید. شاخه edits، با درخواست کشش باز خود، محصول نهایی است، و پیوند به اولین commit در درخواست کشش این است که چگونه آن را در دسترس زبان‌آموزی قرار دهید که می‌خواهد ارائه را مرور کند.< /p>

GitHub با قرار دادن پیچیدگی بیزانسی ابزار اصلی، Git، در یک رابط بسیار دوستانه‌تر، آنچه را که در اینجا نشان داده‌ام، فعال می‌کند. اما آنچه برای یک کدنویس دوستانه است احتمالاً همچنان معلم انگلیسی را تحت تأثیر قرار می دهد. من کاملاً می‌توانم ابزارهایی را تصور کنم که پیرامون GitHub API پیچیده شده باشد که این تکنیک را برای معلمان و زبان آموزانی که بر مهارت نوشتن و ویرایش متمرکز هستند ساده‌تر کند.

در همین حال، می‌توان از GitHub برای دستیابی به یک نتیجه خوب استفاده کرد. آیا عملی است؟ این برای من نیست که بگویم. من خیلی گذشته که بتوانم این چیزها را از چشم یک مبتدی ببینم. اما اگر دوست معلم انگلیسی شما می‌خواهد این را امتحان کند، من دوست دارم بدانم آیا می‌توانند این دستور العمل را دنبال کنند یا خیر، و اگر چنین است، آیا فکر می‌کنند که می‌تواند به زبان‌آموزان کمک کند تا نویسنده و ویراستار بهتری شوند.