Doğrudan cevap
Issue; hata, görev, fikir veya soru gibi takip edilmesi gereken işi; bağlam, yeniden üretim adımları, başarı ölçütü ve sorumluluk bilgisiyle kayıt altına alan çalışma öğesidir. Bu bölümde noktayı özellikle “Doğrudan cevap” bağlamına uygula ve sonucu doğrulayacak ya da değiştirecek kanıtı kaydet.
Bu derste “Issue, Görev ve Hata Kaydı” yalnız terim tanımı olarak bırakılmaz. Öğrenci “Issue, Görev ve Hata Kaydı” kavramını bir ekibin izleyebildiği ve güvenle değiştirebildiği proje geçmişi üzerinde örnek, karşı örnek, uygulama ve yeniden kontrol yoluyla göstermelidir.
Neden önemli?
Sözlü “şu bağlantı çalışmıyor” bildirimi hangi sayfa, cihaz ve koşulda sorun olduğunu göstermeyebilir. İyi issue, başka bir kişinin problemi görmesini veya görevi tamamladığını doğrulamasını sağlar.
Başlangıç vakası: Bir kullanıcı “linkler yanlış” diyor. Issue yalnız bu cümleyi taşırsa geliştirici sorunu bulamaz; ekran görüntüsü, tıklama koordinatı ve görünmez overlay bulgusu eklendiğinde hata tekrarlanabilir olur.
“Issue, Görev ve Hata Kaydı” konusunda görünen ilk belirti gerçek nedeni saklayabilir. Bu nedenle çözüm veya komut önermeden önce okuyucu, görev, sürüm, başlangıç durumu ve doğrulama ölçütü yazılır. Sonuç yalnız “anlaşıldı” ya da “çalıştı” biçiminde değil, kimin hangi adımı hangi kanıtla tamamladığı biçiminde raporlanır.
Öğrenme hedefleri
- Açık başlık kararını açıklamak ve kanıtlamak
- Bağlam ve adımlar kararını açıklamak ve kanıtlamak
- Beklenen–gerçek kararını açıklamak ve kanıtlamak
- Tamamlanma ölçütü kararını açıklamak ve kanıtlamak
- Yanlış veya eksik kaydı teşhis etmek
- Güvenlik, lisans ve mahremiyet sınırını yazmak
Bu hedefler tamamlandığında “Issue, Görev ve Hata Kaydı” okunmuş bir sayfa değil; yardımsız açıklama, konuya özel kayıt, hata teşhisi ve yeni bağlama aktarım yoluyla gösterilmiş beceri olur.
Ana kavramlar ve karar noktaları
1. Açık başlık
Belirti ve etkilenen alan kısa başlıkta görünür. “Issue, Görev ve Hata Kaydı” içinde bu ilke, değişikliğin yalnız çalışmasını değil; geçmişte izlenmesini, ekip tarafından incelenmesini ve güvenle geri alınabilmesini sağlar.
Beklenen kanıt: Aranabilir başlık. “Issue, Görev ve Hata Kaydı” kanıtının tarihi, proje sürümü, kullanılan araç ve kontrol sonucu birlikte yazılır. Böylece başka bir öğrenci yalnız son dosyayı değil, kararın nasıl oluştuğunu da izleyebilir.
Sınır sorusu: “Issue, Görev ve Hata Kaydı” açısından okuyucu, ekip, araç, sürüm veya yayın ortamı değiştiğinde bu ilkenin hangi bölümü yeniden tanımlanmalıdır? Cevap mutlak bir kural yerine koşul, risk ve doğrulama yöntemi içermelidir.
2. Bağlam ve adımlar
Cihaz, sürüm, başlangıç ve yeniden üretim adımları yazılır. “Issue, Görev ve Hata Kaydı” içinde bu ilke, değişikliğin yalnız çalışmasını değil; geçmişte izlenmesini, ekip tarafından incelenmesini ve güvenle geri alınabilmesini sağlar.
Beklenen kanıt: Yeniden üretim kaydı. “Issue, Görev ve Hata Kaydı” kanıtının tarihi, proje sürümü, kullanılan araç ve kontrol sonucu birlikte yazılır. Böylece başka bir öğrenci yalnız son dosyayı değil, kararın nasıl oluştuğunu da izleyebilir.
Sınır sorusu: “Issue, Görev ve Hata Kaydı” açısından okuyucu, ekip, araç, sürüm veya yayın ortamı değiştiğinde bu ilkenin hangi bölümü yeniden tanımlanmalıdır? Cevap mutlak bir kural yerine koşul, risk ve doğrulama yöntemi içermelidir. Bu bölümde noktayı özellikle “2. Bağlam ve adımlar” bağlamına uygula ve sonucu doğrulayacak ya da değiştirecek kanıtı kaydet.
3. Beklenen–gerçek
İstenen davranış ile gözlenen sonuç ayrılır. “Issue, Görev ve Hata Kaydı” içinde bu ilke, değişikliğin yalnız çalışmasını değil; geçmişte izlenmesini, ekip tarafından incelenmesini ve güvenle geri alınabilmesini sağlar.
Beklenen kanıt: Karşılaştırma. “Issue, Görev ve Hata Kaydı” kanıtının tarihi, proje sürümü, kullanılan araç ve kontrol sonucu birlikte yazılır. Böylece başka bir öğrenci yalnız son dosyayı değil, kararın nasıl oluştuğunu da izleyebilir.
Sınır sorusu: “Issue, Görev ve Hata Kaydı” açısından okuyucu, ekip, araç, sürüm veya yayın ortamı değiştiğinde bu ilkenin hangi bölümü yeniden tanımlanmalıdır? Cevap mutlak bir kural yerine koşul, risk ve doğrulama yöntemi içermelidir. Bu bölümde noktayı özellikle “3. Beklenen–gerçek” bağlamına uygula ve sonucu doğrulayacak ya da değiştirecek kanıtı kaydet.
4. Tamamlanma ölçütü
Issue kapanmadan önce geçmesi gereken testler belirtilir. “Issue, Görev ve Hata Kaydı” içinde bu ilke, değişikliğin yalnız çalışmasını değil; geçmişte izlenmesini, ekip tarafından incelenmesini ve güvenle geri alınabilmesini sağlar.
Beklenen kanıt: Acceptance criteria. “Issue, Görev ve Hata Kaydı” kanıtının tarihi, proje sürümü, kullanılan araç ve kontrol sonucu birlikte yazılır. Böylece başka bir öğrenci yalnız son dosyayı değil, kararın nasıl oluştuğunu da izleyebilir.
Sınır sorusu: “Issue, Görev ve Hata Kaydı” açısından okuyucu, ekip, araç, sürüm veya yayın ortamı değiştiğinde bu ilkenin hangi bölümü yeniden tanımlanmalıdır? Cevap mutlak bir kural yerine koşul, risk ve doğrulama yöntemi içermelidir. Bu bölümde noktayı özellikle “4. Tamamlanma ölçütü” bağlamına uygula ve sonucu doğrulayacak ya da değiştirecek kanıtı kaydet.
Adım adım örnek inceleme
Başlangıç vakası: Bir kullanıcı “linkler yanlış” diyor. Issue yalnız bu cümleyi taşırsa geliştirici sorunu bulamaz; ekran görüntüsü, tıklama koordinatı ve görünmez overlay bulgusu eklendiğinde hata tekrarlanabilir olur. Bu bölümde noktayı özellikle “Adım adım örnek inceleme” bağlamına uygula ve sonucu doğrulayacak ya da değiştirecek kanıtı kaydet.
Durum ve niyet: Önce açık başlık ile bağlam ve adımlar ayrılır. Hangi dosyanın değiştiği kadar, değişikliğin neden gerektiği ve ortak geçmişte nerede durduğu da yazılır.
İş birliği adımı: Beklenen Robotik Sistemler; gerçek Mezuniyet 2026. örneği dal, commit, issue veya inceleme kaydıyla ilişkilendirilir. Takım üyesi yalnız son sonucu değil, değişikliğin kapsamını ve doğrulama ölçütünü görebilmelidir.
Birleştirme ve kurtarma testi: “Issue, Görev ve Hata Kaydı” için Tamamlanma ölçütü ile sonuç doğrulanır. Tek başarılı komut yerine status, diff, log ve ilgili testler saklanır. Hata oluşursa geçmişi gizlemek yerine güvenli geri alma veya yeni düzeltme commit’i hazırlanır.
Karşı örnekle derinleştirme
“Issue, Görev ve Hata Kaydı” senaryosunda tek bir koşulu bilinçli olarak değiştir: hedef okuyucuyu başlangıç düzeyinden deneyimli kullanıcıya, aracı yerel dosyadan ortak depoya, metni tek dilden iki dile veya bireysel görevi takım çalışmasına çevir. Sonucun neden değişmesini beklediğini önce yaz; ardından aynı kanıt zincirini yeni koşulda sınamayı dene.
Tahminin tutmadığında başarısızlığı silme. “Issue, Görev ve Hata Kaydı” için hangi varsayımın yanlış olduğunu, hangi belgenin veya Git kaydının eksik kaldığını ve bir sonraki sürümde hangi kontrolün yapılacağını belirt. Böylece “Issue, Görev ve Hata Kaydı” ezberlenmiş bir tarif değil, farklı bağlamlarda sınanabilen bir karar sistemi olur.
Uygulama laboratuvarı
- 1. adım: Sorunu belirti üzerinden kısa başlıkla yaz.
- 2. adım: Ortam ve sürüm bilgisini ekle.
- 3. adım: En az sayıda yeniden üretim adımını sırala.
- 4. adım: Beklenen ve gerçek sonucu ayrı yaz.
- 5. adım: Ekran görüntüsü veya logu özel verilerden temizle.
- 6. adım: Kapanış için ölçülebilir doğrulama ölçütü belirle.
| Karar alanı | Kontrol örneği | Kanıt | Yorumlama ölçütü |
|---|---|---|---|
| Açık başlık | Mobilde Akademi kartı yanlış sayfayı açıyor. | Aranabilir başlık. | Belirti ve etkilenen alan kısa başlıkta görünür. |
| Bağlam ve adımlar | 390 px, menü kapalı, kart merkezine tıkla. | Yeniden üretim kaydı. | Cihaz, sürüm, başlangıç ve yeniden üretim adımları yazılır. |
| Beklenen–gerçek | Beklenen Robotik Sistemler; gerçek Mezuniyet 2026. | Karşılaştırma. | İstenen davranış ile gözlenen sonuç ayrılır. |
| Tamamlanma ölçütü | 12 kart gerçek tıklamada doğru URL’ye gitmeli. | Acceptance criteria. | Issue kapanmadan önce geçmesi gereken testler belirtilir. |
Kanıt paketi: Issue başlığı, ortam, adımlar, beklenen/gerçek sonuç, temizlenmiş kanıt, etiketler ve kapanış testi saklanır.
Uygulama boyunca yalnız başarılı son ekran saklanmaz. Başlangıç durumu, hata belirtisi, karar gerekçesi, yapılan değişiklik ve yeniden kontrol sonucu yan yana tutulur. Böylece “Issue, Görev ve Hata Kaydı” estetik tercih veya ezberlenmiş komut değil, başkası tarafından incelenebilir bir çalışma olur.
Sürüm kontrol kaydı: “Issue, Görev ve Hata Kaydı” için depo, dal, commit, issue veya inceleme kimlikleri ile test sonucu ilişkilendirilir. Gerçek uzak depoya gönderim gerekmiyorsa uygulama güvenli yerel eğitim deposunda tamamlanabilir.
Aktarım görevi: Aynı kayıt yapısı donanım arızası, belge eksikliği, tasarım görevi ve araştırma sorusunda kullanılabilir. “Issue, Görev ve Hata Kaydı” bilgisini yeni bağlama taşırken hedef okuyucu, takım yapısı, araç sürümü, lisans ve mahremiyet sınırlarını yeniden yazmadan eski şablonu körlemesine kopyalama.
Sık yapılan hatalar ve düzeltme yolları
| Yaygın hata | Neden sorun? | Düzeltme kontrolü |
|---|---|---|
| Çözümü başlığa yazıp belirtiyi gizlemek | Belirti ve etkilenen alan kısa başlıkta görünür. | Açık başlık ilkesine dön; aranabilir başlık. üret ve “Issue, Görev ve Hata Kaydı” kararını yeniden sınırla. |
| “Çalışmıyor” dışında ayrıntı vermemek | Cihaz, sürüm, başlangıç ve yeniden üretim adımları yazılır. | Bağlam ve adımlar ilkesine dön; yeniden üretim kaydı. üret ve “Issue, Görev ve Hata Kaydı” kararını yeniden sınırla. |
| Özel veri içeren ekran görüntüsü eklemek | İstenen davranış ile gözlenen sonuç ayrılır. | Beklenen–gerçek ilkesine dön; karşılaştırma. üret ve “Issue, Görev ve Hata Kaydı” kararını yeniden sınırla. |
| Kapanış ölçütü olmadan issue kapatmak | Issue kapanmadan önce geçmesi gereken testler belirtilir. | Tamamlanma ölçütü ilkesine dön; acceptance criteria. üret ve “Issue, Görev ve Hata Kaydı” kararını yeniden sınırla. |
“Issue, Görev ve Hata Kaydı” çalışmasında hata yalnız yanlış son dosya değildir. “Issue, Görev ve Hata Kaydı” bağlamında hedef okuyucuyu tanımlamamak, sürüm bilgisini saklamak, testi yeniden üretmemek, kaynağı belirtmemek veya ortak geçmişte geri dönüş planı kurmamak da yöntemi zayıflatır. Sorun bulunduğunda bütün çalışmayı kopyalamak yerine bozulan varsayım ve gerekli yeni kontrol yazılır.
Güvenlik, etik ve yayın sınırı
Issue herkese açıksa kişisel bilgi, özel URL, güvenlik açığı ayrıntısı veya anahtar paylaşılmamalı; güvenlik sorunları projenin özel bildirim kanalına yönlendirilmelidir.
Bu sınır “Issue, Görev ve Hata Kaydı” içeriğinin sonuna eklenen küçük not değildir. “Issue, Görev ve Hata Kaydı” belgesi, deposu, issue kaydı, ekran görüntüsü veya sunumu yayımlanmadan önce erişim anahtarı, kişisel bilgi, lisans ve platform yaş kuralları kontrol edilir.
Ders özeti
“Issue, Görev ve Hata Kaydı” için güçlü sonuç; açık amaç, sınırlandırılmış kapsam, konuya özel kanıt, hata analizi ve yeniden doğrulamanın birlikte yazılmasıyla oluşur. Issue; hata, görev, fikir veya soru gibi takip edilmesi gereken işi; bağlam, yeniden üretim adımları, başarı ölçütü ve sorumluluk bilgisiyle kayıt altına alan çalışma öğesidir.
Aynı kayıt yapısı donanım arızası, belge eksikliği, tasarım görevi ve araştırma sorusunda kullanılabilir.
Kontrol soruları
- “Issue, Görev ve Hata Kaydı” konusunun temel amacı nedir?
- Açık başlık neden ilk adımda açıkça yazılmalıdır?
- “Issue, Görev ve Hata Kaydı” senaryosunda hangi kanıt ilk varsayımı sınar?
- “Issue, Görev ve Hata Kaydı” çalışmasında hangi hata sonucu yanıltabilir?
- “Issue, Görev ve Hata Kaydı” için güvenlik veya mahremiyet sınırı nedir?
- “Issue, Görev ve Hata Kaydı” bilgisi başka bir projeye nasıl aktarılır?
Açıklamalı cevaplar
- Issue; hata, görev, fikir veya soru gibi takip edilmesi gereken işi; bağlam, yeniden üretim adımları, başarı ölçütü ve sorumluluk bilgisiyle kayıt altına alan çalışma öğesidir.
- Belirti ve etkilenen alan kısa başlıkta görünür. Bu nedenle aranabilir başlık. hazırlanır ve karar yalnız kişisel yoruma bırakılmaz.
- Bir kullanıcı “linkler yanlış” diyor. Issue yalnız bu cümleyi taşırsa geliştirici sorunu bulamaz; ekran görüntüsü, tıklama koordinatı ve görünmez overlay bulgusu eklendiğinde hata tekrarlanabilir olur. durumunda bağlam ve adımlar ile ilişkili yeniden üretim kaydı. ilk varsayımı görünür kılar.
- Çözümü başlığa yazıp belirtiyi gizlemek. Düzeltmek için beklenen–gerçek ilkesine dönülür ve karşılaştırma. üretilir.
- Issue herkese açıksa kişisel bilgi, özel URL, güvenlik açığı ayrıntısı veya anahtar paylaşılmamalı; güvenlik sorunları projenin özel bildirim kanalına yönlendirilmelidir.
- Aynı kayıt yapısı donanım arızası, belge eksikliği, tasarım görevi ve araştırma sorusunda kullanılabilir.
Kaynak ve doğrulama notları
“Issue, Görev ve Hata Kaydı” için aşağıdaki birincil veya resmî kaynaklar temel çerçeveyi doğrulamak amacıyla seçilmiştir. Araçların arayüzü ve özellikleri değişebileceği için gerçek uygulama tarihinde kullanılan sürüm ve ortam ayrıca kaydedilmelidir.
Sonraki adım
Bu ders için bir cümlelik açıklama, konuya özel kanıt ve düzeltilmiş bir hata kaydı bıraktıktan sonra sıradaki içerik <strong>Değişiklik İnceleme ve Yapıcı Geri Bildirim</strong>. Önceki kanıt tamamlanmadıysa yalnız sayfa sayısını artırmak için ilerleme işaretlenmez.