QA/BSA/BugReport Details/ar

التلميحات التاليه سوف تساعدك في استعمال اختيارات بقزيلا المختلفه وادوات الادخال بالشكل الصحيح, ويرجى ذكر التلميحات في تقرير العله

من الممكن ان تستعمل مساعد تقديم العلل (وهو تحت التجربه حاليا)


 * اذا كنت تريد كتابة تقرير عله, أولا انقر على المكون الفرعي المناسب تحت المكون الأساسي(اذا كانموجود تلقائيا, اعمل على تطويره) اذا اردت ان تبحث في بقزيلا, من الممكن ان تكون مشكلتك مكتوبه مسبقا. التلميحات تفيد في تمييز الوظائف المترابطه.


 * ⓘ يؤدي الى المساعدة في المكونات الفرعيه
 * اذا لم تجد تقرير عله يتعلق بمشكلتك, انقر ► خلف المكونات الفرعيه لتصل الى صفحة التقديم المعده, يجب عليك اكمال سطر العنوان, اختيار نظام التشغيل, #الاصدار, وبالتاكيد في النهاية تضيف تقريرك.


 * اذا وجدت تقرير يتعلق بمشكلتك, من الافضل اضافة بعض المعلومات المفيده من تحقيقاتك؟

الاصدار
الاصدار المنتقى يجب ان يوضح اصدار LibreOffice الذي تظهر فيه المشكله. خاصة للتراجعحيث انه من المهم ان يكون لديك علامة للاصدار الذي ظهرت فيه المشكله

اذا كان اصدارك غير متوفر في منتقي الاصدارات, فضلا اضف المعلومات في الملخص مثل [OOO340m1 (Build:401)] او مشابه واستخدم غير معروف في منتقي الاصدار! من الممكن ان تجد نسخه لم تنشأ, معلوماتتتعلق بالاصدار الاخير هنا
 * اعضاء فريق ضمان الجودة يجب عليهم ان يحاولو ايجاد هل الاصدارات السابقه تضررت من نفس المشكله او لا مع محاوله تعديل الاصدار المنتقى ان امكن ذلك
 * اذاوجدت ان المشكله لم تتواجد في الاصدارات السابقه او في مجموعة ( OOo 3.3) التراجع.
 * اذا كان البحث ثنائي الشطر اظهر ان المشكله قدمت في اصدار يسبق الاصدار الذي اخترته, فضلا اوضح الاصدار بعد الاختبار
 * بخصوص التقارير LibreOffice المتنقله فضلا اكمل بنفس الاسلوب. اذا كانت المشكله لا تلاحظ الا في LibreOffice المتنقل, فضلا ابدأ باختصار الاسطر باستخدام " [Portable] " في نفس الوقت مع الاصدار من منتقي الاصدار


 * لمشاهدة Dev-Builds الاطلاع على اصدارات خاصه


 * للعللالموروثه من OOo استعمل اول الاصدارات المتوفره LibO اصدار LibO 3.3.0 Beta2

الاصدارات الجديده 2012-06-20
المحتوى من المنتقي سوف تجرى عليه بعض التعدلات ليكون في المستقبل اصدار يظهر في المنتقى يشابه اصدار وقائمة مساعدة/حول البرنامج LibreOffice. وبعد المناقشه في libreoffice-qa اتخذنا هذا القرار, لذا فسوف يتم البحث عن اصدار جديد


 * سوف يكون هناك متعلقات اخرى البناء اليومي بعد alpha1, هذا المفهوم ينتج اصدارات متعدده تقارب 0 تقرير, ولكن هذه تفاصيل صغيره, لكن 3.6.0.0beta2 ستكون اول بناء يتبع هذه الخطه.
 * الاصدارات القديمة الى LibO 3.5 فقط سوف تخسر الاسبقيه في المنتقي
 * لا يوجد حاجه الى تعديلات يدويه, العلل الموجوده سوف تاخذ الاصدارات الاحدث بشكل الي بدون اي ازعاج.
 * القيد الوحيد الموجود في الظهيره مساعد تسليم العللسوف لن يعمل لفتره بسيطه بين التغيرات البسيطه في قاعدة بيانات بقزيلا وفي مساعد التحديثات.

المكونات
فضلا قم باختيار مكون مناسب لتقريرك. اذا وجدت عله تاكد هل المتضرر التطبيق الموجود في جهازك او ان العله عامه للجميع(او على الاقل مجموعه من المستخدمين). الكلمات المستعمله للمكونات الفرعيه يجب ان تساعد في تمييز هذه المكونات الفرعيه من اي معاني اخرى للكلمات.



الفلاتر والتخزين
استيراد وتصدير الشفرات, البنيه التحتيه لوسائل الادخال/ الاخراج مشترك بين الطبيقات. الوحدات مثل (فضلا اضف اسم الفلتر مثل SVG او ماشابه في خانة العنوان في بقزيلا) و لاي شيء اخر مشابه. غالبا ممتع للمطورين



البنيه
التطبيق. الشفرات المشتركه بين التطبيقات ليست جزء من اجزاء الادوات الرسوميه كانت موجوده في سطح المكتب والان تحولت لشكل ثنائي في StarOffice 5 - لاي شيء اخر يتعلق بالبنيه
 * هذه شفرات الواجهة الرسمويه لسطح المكتب, واكثرها الأن مهمل.



تكدس رسومي
مجموعة ادوات VCL, طبقات الرسم, وجميع وظائف الطباعه الغير محدده, ممتعه للمطورين



sdk
UNO بيئه وقت التشغيل, UNO API, SDK, ممتعه للمطورين

Libreoffice
If you can't find any other appropriate component: for all other issues.

Linguistic
For problems with (check), ,, . Please do not use this component if your problem only affects a particular language. for all other problems!

Localization
For all problems that are related to a particular Language version of LibreOffice. Alternatively you can use one of the other components and set the l10n keyword. for User Interface problems (bad translations ...),  for all other problems!

Presentation
For all problems concerning the presentation application. If applicable, please use one of the following key words in the Summary for more detailed specification: ,, , , , , , for problems with running presentation, ,, , for all other problems!

Spreadsheet
For problems concerning the spreadsheet application. If applicable, please use one of the following key words in the Summary for more detailed specification: ,, , , , , , , , , , , for all other problems!

General hints
Please don't mix up key words for Subject line from this page with the Keywords in Bugzilla selection. Some hints how to use Subject Line Key Words:
 * upper case will be visible enough for most key words, square brackets only are useful if the key word can be confused with parts of a word ("... unable to qUIt ...")
 * Use 2 key maximum
 * Use key words exactly identical to the letter, but you may integrate them into the subject line sentence like"WIKIHELP [UI] not available in all Languages"

Initial state
You can find general information concerning bug fixing workflow and related Bug status here. In accordance to hints in FreeDesktop Bugzilla, please use UNCONFIRMED if you are not absolutely sure that you really found a general problem and that it's not limited to your PC, that it has not been already reported, that it's a real bug and not a feature, ... You will have to make Advanced Fields visible to see the status picker. If you reach the bug submission page from This Wiki, UNCONFIRMED will be selected by default. Please also decide for UNCONFIRMED if you only can report the effect without complete background information. It's really important to release developers from such basic research. So an overcautious UNCONFIRMED generally is better than an overhasty NEW. A sample for a bug report that better should have had UNCONFIRMED as initial state is, please see how much information has been gathered additionally to the original report.

Reports with status Unconfirmed will be checked by other users, if the problem is reproducible with a current version, considered as a real bug and description is complete the status will be set to NEW. If you can't reproduce a problem although you tested with an identical system configuration like the reporter and see a serious suspect that current Status NEW is incorrect (for example because there might be no real bug, but some user error), please leave a comment!

Status NEEDINFO
This status is not available for new bugs. Should be used for existing bugs if more information is required from reporter or commenters before bug fixing can be started and before the Bug has been assigned. More details here!

How to reopen Bugs

 * If you do not have much experience in Bugzilla, please only write your suspect that the bug reappeared in a comment. Someone from QA or a developer will take care.
 * If the bug is on Status FIXED, please check very carefully whether you really observe that the old bug reappeared (that happens really seldom) or whether you only observe very similar symptoms as mentioned in the FIXED bug. If you are not a very experienced user or if there is any little doubt, please submit a new Bug report and mention your suspect in the report (citing old FIXED Bug number).
 * If the old bug is on Status WORKSFORME feel free to reopen after you checked carefully that you really observe the reported bug and whether your LibreOffice Version can contain the FIX therefore check the Whiteboard target information!).

Version Picker: Particular Versions

 * Master:
 * Master old -3.6 is for all Bugs that have been observed in Daily Builds from a MASTER or Daily subdirectory of each folder until LibreOffice 3.6. Because of the very wide Range, especially for bugs observed in 3.5 Master (Summer 2011), the most early 3.5 released version where the problem also has been observed might be more useful, but a general recommendation is difficult.
 * Starting with LibO 4.0 every Major Release will get it's own Master Version in Bugzilla (like 4.0.0.0.alpha0+ Master )
 * In Master Build Bug reports please always also mention Tinderbox name and Time stamp from downloaded file. That will ease to find out whether a build used for review is more current or not compared to reporter's version.
 * Please always check whether the problem also can be observed in the current stable builds, use LibO Master only for problems only visible in Master versions.
 * Subject Line of the report should start with pseudo key word MinGW if a problem only can be observed in those Master builds
 * 3.4 Daily is for all Bugs that have been observed in LibO 3.4 related Daily Builds from libreoffice-3-4 subdirectory of each folder. These builds are no longer be available starting 2012.
 * 3.5 Daily is for all Bugs that have been observed in LibO 3.5 related Daily Builds from libreoffice-3-5 subdirectory of each folder.

Whiteboard
Here you can add some tags to make the bug easier to find for queries. Do NOT use it for random comments! Separate the tags you use in Whiteboard status by a whitespace, do not use commata. The one tag in Whiteboard status should never contain whitespace itself, use underscore instead (e.g. "data_loss"). Following standard phrases have been used frequently:
 * bibisected36older for a Bug what has not been observed in a late LibO 3.5 but appeared in all 3.6 Versions available for tester for bibisecting.
 * bibisected35, bibisected35older and bibisected35newer bibisected regression as per QA/HowToBibisect.
 * bibisected35: this bug has been bisected in the range of MELD_LIBREOFFICE_REPOS and libreoffice-3-5-branch-point tags.
 * bibisected35older: the commit that introduces the bug is older than MELD_LIBREOFFICE_REPOS tag.
 * bibisected35newer: the commit that introduces the bug is newer than libreoffice-3-5-branch-point tag.
 * You may add bibisectrequest if you can't do a Bibisect, but believe that that would be useful because the Bug has already been reproduced with Linux and probably appeared with a Version for what Bibisect is available
 * If you can do Bibisect and are willing to help to narrow down the Version where the bug appeared, you can use this to get message for new Bugs with Whiteboard entry bibisectrequest (what should be removed when you did the Bibisect).


 * BSA means that this bug has been submitted using the Bug Submission Assistant
 * numberformat
 * Used by developers to identify bugs related to Calc's number format handling code.


 * perf
 * for performance issues


 * odf is a very general keyword for any kind of interoperability problem in consuming or producing ODF documents
 * odf_validation is specifically for bugs about LO producing invalid or non-conforming ODF documents
 * target:X.Y.Z for the next Release where the fix will be available (no Beta, RC, ...)
 * It must be target followed by a colon then the version number.  It must be one word without whitespace in order for it to be usable via regexp search.
 * A target marker should always be set by the developer working on the bug, never by the reporter.
 * At the time of bug resolution, the developer should set the target marker to indicate to which version the bug fix will be applied (if it has not been already set).
 * If a bug in a stable version vanished in the Master without a known fix, a developer or QA member should change the Bug report Status to WORKSFORME with Whiteboard entry with the Master version (September 2011: target:3.5.0). In a comment the complete Master build ID what has been tested without seeing the bug should be mentioned. So other users seeing the problem during their tests can find out easily where they can await a version without the bug.
 * experimentalEnabled for behavior which is evident only when the user has checked Tools > Options > LibreOffice > General > "Enable experimental (unstable) features".
 * rtf_filter: to distinguish general RTF related bugs form particular ones related to the new RTF import filter. This helps to track down those new filter related bugs more easily. Use of this key word needs detailed knowledge concerning new filter. Experts are Miklós Vajna, Lubos Lunak, Cédric Bosdonnant (for example).

You can find additional key words for Whiteboard on Development/Easy Hacks Bugzilla Whiteboard Status

Severity
Below is a general description of each level of severity from most severe (Blocker) to least severe (Enhancement). These are meant to be general guidelines for QA individuals trying to triage bugs. At the end of the section is a flowchart which provides an example of how one could potentially triage severity of bugs as they are moved from UNCONFIRMED to NEW or ASSIGNED. These are meant to be guidelines not strict standards, any suggestions to make the process better should be made through the QA mailing list where we can discuss potential changes.


 * Blocker
 * Bug so grave it should block the release; see our Release Criteria


 * Critical
 * crashes, loss of data, severe memory leak


 * Major
 * major loss of function


 * Normal
 * regular issue, some loss of functionality under specific circumstances


 * Minor
 * minor loss of function, or other problem where easy workaround is present


 * Trivial
 * cosmetic problem like misspelled words or misaligned text


 * Enhancement
 * Request for enhancement

Example Flowchart(s)
Feel free to amend this section with examples of how triaging severity can be done. There is no one right way but when it is being done the QA member should do everything in their power to be consistent. Also, try to comment when changing things so that other members and our users know your thought process.

Example 1.jpg

Keywords

 * regression
 * this worked in a previous release of LibreOffice, so the bug has been recently introduced.


 * l10n
 * localization issue (don't use i18n, use l10n)


 * patch
 * there is a patch attached to the issue


 * security
 * security related issue


 * patcheswelcome
 * bug/enhancement which has been closed due to lack of time/importance to implement but developers welcome to make a patch if they have the time or desire to do so.