QA/BugTriage/tr

Giriş
Bu belge LibreOffice için hataların acil önceliklerinin nasıl olacağı hakkında bilgi sağlar. Hata raporlarını onaylamak, öncelik vermek ve düzenleme işlemlerinin tamamı acil önceliklerinin anlamını verir ve bu alan LibreOffice'in herkes için daha iyi bir ürün olması için sınırlı programlama yetenekleri ile yeni katılımcılar ve/veya katkıda bulunanlar için iyi bir yerdir. Acil öncelik belirlemek geliştirmenin önemli bir yönüdür bu hem kullanıcılar hem de geliştiriciler için faydalı.

This document provides information on how to triage bugs for LibreOffice. Triaging is the name given for confirming, prioritizing, and organizing bug reports and is a good place for new contributors and/or contributors with limited programming abilities to help LibreOffice become a better product for everyone. Triaging is an incredibly important aspect of development that benefits users and developers alike.

Diğer QA Üyelerini Bulabileceğin Yer
QA ekibi ile iletişime geçeceğin bir kaç yer var, birçoğu öncelik soruları için yardımcı olabilir..


 * 1) Mail Listesi
 * 2) *libreoffice-qa@lists.freedesktop.org
 * 3) *libreoffice@lists.freedesktop.org
 * 4) IRC Kanalı
 * 5) QA Üyeleri QA üyelerinin listesi burada (Eğer QA için katkıda bulunmak istiyorsanız kendi adınızı eklemekten çekinmeyin.). Eğer kullanıcının onlara direkt erişimine izin verildiyse bu durumda çekinmeyin.
 * 6) * QA Üye Listesi
 * 1) QA Üyeleri QA üyelerinin listesi burada (Eğer QA için katkıda bulunmak istiyorsanız kendi adınızı eklemekten çekinmeyin.). Eğer kullanıcının onlara direkt erişimine izin verildiyse bu durumda çekinmeyin.
 * 2) * QA Üye Listesi

There are a few places where you can find/contact members from the QA team, many of whom can help with triaging questions and are actively triaging themselves.


 * 1) Mailing Lists
 * 2) *libreoffice-qa@lists.freedesktop.org
 * 3) *libreoffice@lists.freedesktop.org
 * 4) IRC Channels on Libera Chat
 * 5) QA Members Here is a list of QA members (feel free to add your own name if you intend on contributing to QA). If the user has given you permission to contact them directly, feel free to do so. Also you'll find them hanging out in the chat rooms somewhat frequently.
 * 6) * QA Member List
 * 1) QA Members Here is a list of QA members (feel free to add your own name if you intend on contributing to QA). If the user has given you permission to contact them directly, feel free to do so. Also you'll find them hanging out in the chat rooms somewhat frequently.
 * 2) * QA Member List

Acil Öncelikli Hata Adımları
Bu bölümde doğru sırayla acil öncelik için gerekli adımları listelenir. Bu klavuz kısa ve öz olmayı hedefliyor, adımlardaki özelliklerle ilgili linkler bazı bölümlerde daha fazla bilgi sağlayacak. Acil öncelik işlemleri üç parçaya bölünebilir İlki "hazırlık", ikincisi "yeniden türetmesi üçüncüsü "önceliği"

This section lists the steps necessary in order to triage correctly. This guide aims to be concise, links in some sections will provide more information relevant to the particular step. The triage process can be essentially broken up into three parts, the first being "preparation" the second being "reproducing" the third being "prioritization".

Adımların özeti

 * 1) Acil öncelik için hataları bulmak
 * 2) Hata raporlarında ön eleme yapmak
 * 3) Hata çiftlerini aramak
 * 4) Hata raporlarındaki bilgilerin kontrolünü sağlamak
 * 5) Hatayı yeniden oluşturmaya çalışmak
 * 6) Hata durumunu ayarlamak
 * 7) Hata önceliği belirlemek
 * 8) Geliştiriciyi bilgilendirmek --Sadece özel durumlarda gerekli örneğin hata engelleyici/kritik gözüküyorsa


 * 1) Find Bugs to Triage
 * 2) Pre-filter Bug Reports
 * 3) Search for Duplicates of Bug(s)
 * 4) Check Information Provided in Bug Report
 * 5) Attempt to Reproduce Bug
 * 6) Set Bug Status
 * 7) Prioritize Bug
 * 8) Notify Developers -- Needed only in very specific cases if bug seems to be a Blocker/Critical.

Hazırlık
In general you'll always want to do the following steps in preparing to triage bugs. Genel olarak sen her zaman aşağıdaki adımları öncelikli hataları hazırlarken yapmak isteyeceksin. Hatırlarsanız hataları yalnızca burada oturum açtığınızda çalışıtabilirsiniz (lütfen buradan bir hesap oluşturunuz eğer önceden yoksa.). Ve bir hesabınız olduğunda, istediğiniz özellikleri ayarlayabilirsiniz ve eğer raporladığın hata için cevaplar alındığında haberdar olmak için 'Otomatik olarak CC listesine beni de ekleyin' seçeneğini seçebilirsin.

Preparation
In general you'll always want to do the following steps in preparing to triage bugs. Remember that you can work on bugs only when logged in (please create an account if you do not already have one). And once you have an account, it is good to go to your preferences and set 'Automatically add me to the CC list of bugs I change' to 'Only if I have no role on them' if you want to be notified whenever someone replies in any of the bug reports you commented in.

Adım 1. Acil öncelik için hataları bulmak
a) Bugzilla Arama

LibreOffice ait hata takip sistemi mevcut bugs.documentfoundation.org. Raporladıktan sonra, bileşen tarafından açık olan diğer hatalara göz atın veya hatalar için özel bir arama yapın:

a) LibreOffice ürününü bulun

b) UNCONFIRMED veya REOPENED durumuna sahip olmalı

c) Sorgulamak için diğer kriterler ne olursa olsun ekleyin

Hata için arama yapın isterseniz acil önceliği olan. Hatalar için özel aramalar olabilir Gelişmis arama formu veya hızlı arama yapmak için Hızlı Arama alanına terimler girilebilir (Bugzilla Hızlı Arama Yardım). Ayrıca aşağıdaki direk linkleri arama için kullanabilirsin. Linke tıkladığınızda Bugzilla sonuç sayfası açılır.


 * Bugs reported in previous 2 weeks
 * Bugs reported in previous 1 month
 * All Bugs that Need Triage Work. (Limited to 500 bugs, full list will take some time to load as it's quite a long list - you can help to change that!)
 * Tüm macOS Hataları, onay gerekenler

Adım 2. Hata Raporlarında Ön Eleme
Bazı hatalar için özel ekipler tarafından özel bakıma ihtiyac vardır.

UX Geliştirmeleri
LibreOffice'in UI/UX geliştirmelerini kapsayan herhangi bir hata UX ekibine verilmelidir.

Any bugs which cover enhancements to the UI/UX of LibreOffice should be given to the UX Team

UX Takımı -- bu geliştirmeye bir göz atın lütfen. Teşekkürler! UX Team -- please take a look at this enhancement. Thanks!
 * 1) ux-advise için Bileşen  değiştirin
 * 2)  Durumu güncelleyin
 * 3) * Eğer istek akla yatkın tamamlanabilir gözüküyorsa, Durum -> YENİ
 * 4) * Eğer istek tamamlanamaz ve açıklanması gerekiyor gözüküyorsa, Durum -> BİLGİ İHTİYACI
 * 5) Satır aralarına yorum bırakın:
 * 1) * If the request looks complete and plausible, Status -> NEW
 * 2) * If the request seems incomplete or needs explaining, Status -> NEEDINFO
 * 3) Leave a comment along the lines of:

Bazı hatalar Bugzilla'ya ait değil. Başka bir yere ait konu listesi için, bakınız Hata Raporlama Sayfası.
 * Eğer bu hatalardan birini Bugzillaya bildirdiğinizde Durum içinRESOLVED NOTOURBUG değişikliği yapın ve yoruma aşağıdakileri ekleyin:

Bizimle iletişime geçtiğin için teşekkürler! Bugzilla bazen Evrenin merkezi gibi hissediyor olsa da, başka bir yerde bildirilmesi gereken birkaç konu var. reported elsewhere. To find the right place to report Sorununuzu bildirmek için doğru yeri bulmak için: https://wiki.documentfoundation.org/QA/BugReport#Not_all_bugs_go_to_Bugzilla

Adım 3. Yinelenen Hataları Bulmak
Yinelenen hatalar RESOLVED DUPLICATE ile işaretlenir bunlar çok benzer veya aynılardır ama farklı kullanıcılar tarafından bildirmişlerdir. Bu tür hatalar Bugzilla tarafından otomatik olarak sayılıyor ve saklanıyor. En sık raporlanan hatalar sayfası. Acil öncelik belirlerken lütfen listeyi kontrol edin ve Bugzilla hataları üzerinden hızlı bir arama yapın yinelenen hatanın olup olmadığını görmek için ama bunun için çok zaman harcamanıza gerek yok. Birçok hata gördüğünde benzer bir hata görmüş olabilirsin bu durumda iki(veya daha çok) hatdan yeni olanı kapatın. Genelde Bugzillaya girilmiş yinelenen hataların sayısını en aza indirmek QA Ekibine zaman kazandıracaktır.

Duplicates are reports which are very similar or identical, but reported by different users. You typically want to keep the NEW status for the report with the most valuable information and close others as RESOLVED DUPLICATE. So even though an older report exists, there is no need to keep it open, if it contains confusing or incomplete information. Closed duplicates are automatically counted by Bugzilla and available at Most Frequently Reported Bugs page. When triaging please, check that list and do a quick search through reports in Bugzilla to see if there are any duplicates of the report you are examining. You don't need to spend a lifetime on this. As you see more reports you may start spotting duplicates without having to use the search.

Yinelenen bir hata bulursanız adım #5 atlayın

Adım 4. Bilgileri Kontrol Et
Bilgileri kontrol etmek geliştirme için önemlidir. Bakmanız gerekenler şunlardır:
 * 1) Açık ve anlamlı özet
 * 2) Problemin açık şekilde anlatılması
 * 3) Sorunu yeniden oluşturabilmek için adımlar  -- eğer özet veya açıklamanız net değilse
 * 4) Eklemeler -- Sorunu yeniden oluşturabilmek için bir çok durumda ekler gerekebilir, eğer eklemeler durumu sağlamıyorsa bu uygun düzeltme yapmaya engel olabilir

Checking information is critical for development. What you should look for is the following:


 * 1) Clear and meaningful summary
 * 2) Clear problem description
 * 3) Steps to reproduce the problem -- if not clear from summary and/or description
 * 4) Attachments -- in many cases attachments are needed to reproduce the problem, if attachment(s) are not provided this can hinder proper fixes
 * 5) If the report refers to external data (screenshots, documents, screencasts, etc.), copy and attach them to the bug, so they don't vanish later and eventually render it unreproducible.

Eğer tüm bilgiler doğru değilse adım #5 atlayın

Adım 5. Yeniden Deneyin
Eğer hatanız "geçti" ise Hazırlık adımları o hatayı yeniden denemenin tam vakti.

Sadece bunu yapın: Gerekli adımları üzerinden gidin ve hata yeniden deneyin, bu kadar basit! Hatayı yenileyebildiğin zaman, aşağıdakileri aklında tut:
 * 1)  Bugzillada hata raporlayan yeterli bilgi bıraktı mı hatayı yeniden oluşturabilmek için veya ekstra adımalra ihtiyacın var mı? Eğer ekstra adımlara ihtiyaç varsa, fazladan bir adım(lar) tanımlamak için bir açıklama ekleyin.
 * 2) Yineleme sonucu aynı sonuç oluştu mu, benzer ama aynı değil mi, veya herşey ksuursuz şekilde çalıştı mı?

If the bug "passed" the Preparation steps it's time to try to reproduce the bug.

Do just that: Go through the steps necessary and try to reproduce the bug, that simple! When you reproduce it, keep these things in mind:
 * 1) Did the bug reporter leave enough information in Bugzilla itself to reproduce the bug, or did you have to take extra steps? If extra steps were needed, add a comment to describe the extra step(s).
 * 2) Did your reproduction lead to the same result, something similar but not identical, or did everything work flawlessly?

Adım 6. Durumu Ayarla
Bu bölüm başarılı acil öncelik belirleme adımlarından en sonununcu "zorunlu" adımdır ve bu sadece #1-#4 adımlar için bir kez yapılabilir(#4 geçerli değilse #3 için)

This section is the last "mandatory" step of a successful triage and can only be done once steps #1–#4 are done (or #3 if #4 isn't applicable).

The STATUS of the bug is dependent on your results from the above steps. Below is a short description of the usage of each status.
 * 1) NEW: Confirmed bug, all information necessary is there
 * 2) NEEDINFO: All information needed to attempt replication is not included in the bug report. Please ask a particular person for a particular information in a comment.
 * 3) RESOLVED: This category comes with several options, if you can't replicate the bug, RESOLVED WORKSFORME is the appropriate STATUS, see HERE for more information.
 * 4) VERIFIED: This option is only available when the current bug status is RESOLVED. You can mark a RESOLVED FIXED bug as VERIFIED, when you can confirm it is fixed with the version mentioned in the bug report. It is also pleasant for the developer who fixed the issue, and is a confirmation the problem is solved now. Otherwise a bug reporter can mark their own bug that is in RESOLVED WORKSFORME state as VERIFIED WORKSFORME to verify it is somehow fixed.
 * 5) INVALID: There are many reasons why a bug can be determined to be invalid, but this usually requires input from other QA members. If you come across a bug that you believe to be invalid, best bet is to get a second opinion from the QA IRC channel or send an email out to the mailing list explaining why you believe the bug to be invalid.
 * 6) UNCONFIRMED: This is the status given to all new bugs that have not gone through triage process. Note that such bug might be also in NEEDINFO state.

ANY time you make changes you should put a comment that politely explains why you made the change

Flowcharts below are examples of how to visually think of setting STATUS. Feel free to edit and upload your own version if you'd like.

[[Media:Unconfirmed Bugs Status Flowchart Version 0.1.pdf|PDF file]]

[[Media:Unconfirmed Bugs Status Flowchart.odg|LibreOffice Draw file]]

Step 7: Regression Testing
Use older versions of LibreOffice to find out whether the bug has been introduced since LibreOffice began.

Download and install a number of old versions, the oldest being LibreOffice 3.3. At a minimum you should have one version from all the main release lines (3.x, 4.x, 5.x, 6.x...).

You have to have some awareness of when various features were introduced into the software to avoid getting irrelevant test results. Please consult other team members, if you are unsure of something.


 * If the bug is present in version 3.3.0, set version to "inherited from OOo" and add the following comment:

This bug is already present in Libreoffice 3.3.0 Changing version to "inherited from OOo"


 * If the bug is not present in 3.3.0 add "regression" to the keywords field and add the following comment:

This bug is not present in Libreoffice 3.3.0, thus it's a regression For regressions that are older than version 3.5.0, also add the keyword preBibisect. For newer regressions add the keyword bibisectRequest and update the version field to match the earliest known problematic version.


 * SI-GUI - Simple GUI app to parallel install on Windows and Android
 * Installing in parallel - Instructions on how to manually parallel install on Windows, Linux and Mac.
 * https://downloadarchive.documentfoundation.org/libreoffice/old/ - Download old releases, betas, and alphas

Step 8: Prioritize Bug
We currently highlight only critical bugs by CC-ing developers and adding keywords. See below for more information.

Prioritizing a bug is relatively subjective, but the triager should always try to be consistent with how they determine a bug's prioritization. The QA team member triaging should have a clear idea of what constitutes each priority state and then try to stick with that methodology. Also, commenting on the bug after prioritizing is helpful in that it lets the bug reporter (as well as developers and other users) know what thought process you used to come up with the priority status.

To prioritize bugs above medium-normal, you need to be added to the contributors group in Bugzilla. In order to get this done, please contact one of the Bugzilla admins.

The flowchart below shows rough guidelines on how to deal with prioritization.

Example 1 JPG

Example 1 Draw

It is usually easier to determine the severity of an issue than try to think of a suitable priority.

Small aesthetic tweaks to the UI can be considered low priority and trivial severity.

Problems that make you angry, but you can tolerate or work around somehow can be set to minor severity.

Bugs that break some functionality and do not have a workaround are normal severity.

Crashes, hangs and freezes resulting from a specific file or command are major severity.

Keywords
The Keywords field holds Keywords pertaining to the categorization of this bug.

Some categories of Keywords include:
 * Broken functionality in specific areas: e.g. filter:xxx (filter:ooxml, filter:doc, filter:rtf, ...), perf
 * Asked or provided debug info: e.g. bibisectRequest, bibisected
 * Easy Hacks: easyHack, difficultyBeginner, skillCPP

One interesting Keyword is needsDevEval. An easyHack is a bug that will most likely not take long to fix and can be done by a new developer and/or a developer without a lot of programming skills. As QA we should NOT mark a bug as easyHack as it requires several additional steps (including finding a developer to mentor for the bug). If you think a bug qualifies as an easyhack, mark as needsDevEval.

Crash reports
Having a crash report (aka backtrace) for a bug makes it easy for a developer to identify what is causing the crash. If a crash report is added to a bug report, the havebacktrace keyword should be added to the Keywords field.


 * QA/BugReport/Debug Information
 * How to get a backtrace with WinDbg

Meta reports
Look at our existing meta reports that collect reports of the same genre. If you find a good fit, add the meta report number to the Blocks field of the report you are triaging.

Comment tags
Comment tags act as notes that help everyone get a quick overview of the comment history and value/relevance of individual comments. Click the tag text in the header of a comment, input your tag and press enter. There is no need to save the report. You can invent new tags or use existing tags. The tag input field supports auto-completion.

Entering one of these tags make the comment hidden by default: obsolete, spam, me-too, off-topic, abusive, no-value, bibisection, noise. You can show a hidden comment by clicking on the "Toggle comment display" widget in the comment header. You can also hide regular comments and show tagged comments by clicking on the tag name of your choosing under the "Comment Tags" list next to the bug description (comment 0). Click Expand all comments to show everything.

Checking Additional Info
As a triager we should try to check the information that was originally reported by the bug reporter. Things to check include:
 * Product
 * Version
 * Platform

Adding Developer to CC List
This step should only be done if you're sure that it is important enough to CC a developer. If you think that a bug is serious enough that it deserves extra attention but maybe does not belong in the category of Most Annoying Bugs, then you should seek out an expert for additional input. Please try to use this with care as we don't want to inundate our expert developers with minor bug pings. To add the user simply add their name to the CC list and put a comment on the bug telling the developers why you've added them to the CC Anyway, the right names can be found in the list of experts.

Adding QA to CC List
This mostly is not used but if you feel like adding yourself or another QA member to the list might be useful, feel free to do so. Again, please make sure to add a comment if you're adding someone else to the list, otherwise they might get irritated at not knowing what's going on.

Interoperability testing
If the requirement for testing is opening or saving a file with Microsoft Office and you don't have access to the software, you might make use of Office Web Viewer. It works with Word, Excel, PowerPoint and ODF documents. You need to upload the document somewhere and then add the URL to the end of this link:

https://view.officeapps.live.com/op/view.aspx?src=

You can then click the button in the top menu and finally  to get access to a PDF rendering of the document. This will both allow you to see how the document looks like in the latest version of Microsoft Office and share the PDF in Bugzilla.

Bugzilla attachment links work with the viewer.

To conveniently use the live viewer in Firefox
https://view.officeapps.live.com/op/view.aspx?src=%s
 * Add a new bookmark
 * Set some Name
 * Set the URL to:
 * Set a Keyword, such as lv, press OK.
 * Now you can use the bookmarks keyword plus a bugdoc URL in the URL bar to open the bugdoc in the Office live viewer:

lv https://bugs.documentfoundation.org/attachment.cgi?id=180059

Special Triage Notes for the QA Team
Here are some notes for Advanced Triagers on the QA/Team. If you're new, don't worry about any of this!

Bug reports that are difficult to triage or close
Sometimes we need special software or hardware to reproduce a bug or we face some other difficulty that prevents us from investigating. For these cases we have: The collection uses the MediaWiki Bugzilla extension, which pulls data from meta reports and various other queries.
 * A collection of UNCONFIRMED bugs that QA team members are having a hard time with.

Extensions
It is best to get the creator of the extension involved in triaging. The responsibility for contacting the creator is on the bug reporter.

Also read:
 * QA/BugReport/Extensions

Locale-related controversy
Sometimes we are faced with hot topics related to locales. There might be a situation where a national standard for something differs from the actual practice. In these cases, it can be useful to direct the issue reporter to the Unicode Common Locale Data Repository and their survey tool.

Suggested Triage Order
The tables below represent a suggested order to approach triaging. The goal of QA is to confirm the worst bugs first.