EncyclopAtys - User contributions [en]

Template:Moniq's Apps

2022-03-30T15:44:51Z

Moniq: URLs updated

<noinclude>{{Trad
|DE = Template:Moniq's Apps|DEs= 1
|EN = Template:Moniq's Apps|ENs= 0
|ES = Template:Moniq's Apps|ESs=1
|FR = Template:Moniq's Apps|FRs= 0
|RU = Template:Moniq's Apps|RUs= 1
|H =
|palette=
|ref=
|com=
}}</noinclude>
<includeonly>{| class="wikitable"
|-
! Icon !! Application !! AppZone !! Additional details
|-
|[[File:BagApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/bagapp/?sekce=document&klic=bagapp Bag App]''' 0.6 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1977 /appzone 1977]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1977 Install] || Tool to browse inventory cache obtained from character and/or guild API. URL: http://tears.family/STABLE/bagapp/
|-
|[[File:Bbg ico.png]]|| '''Blabla Game''' ''(part of Lang App)'' || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2413 /appzone 2413]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2413 Install] || A little translation game with Atys languages URL: http://tears.family/STABLE/langapp/?sekce=bbg
|-
|[[File:Bbt ico.png]]|| '''Blablator''' ''(part of Lang App)'' || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2414 /appzone 2414]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2414 Install] || Blablator, dummy brute-force translator to and from Atys languages URL: http://tears.family/STABLE/langapp/?sekce=blablator
|-
|[[File:Book of Guilds-icon.png]]|| '''Book of Guids''' first release || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1960 /appzone 1960]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1960 Install] || Livre des Guildes d'Atys - Libro de Gremios - Buch der Gilden URL: http://tears.family/STABLE/bog_first/
|-
|[[File:Deeplist.png|32px]]|| '''DeepList''' 0.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2567 /appzone 2567]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1977 Install] || Application manage specific Atys terms with dictionary export API URL: http://tears.family/STABLE/deeplist/
|-
|[[File:FameTracker-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/fameapp/?sekce=document&klic=fameapp Fame Tracker]''' 0.9.2 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2132 /appzone 2132]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2132 Install] || Suivi de la Renommée - Ruhm-Übersicht - Rastreador de Fama URL: http://tears.family/STABLE/fameapp/
|-
|[[File:LangApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/langapp/?sekce=document&klic=langapp Lang App]''' 0.9.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2135 /appzone 2135]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2135 Install] || Interface to translate applications and browse old Blablatys dictionary URL: http://beta.kdyne.net/rygreg/STABLE/langapp/
|-
|[[File:LevelTracker-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/levelapp/?sekce=document&klic=levelapp Level Tracker]''' 0.5 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2324 /appzone 2324]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2324 Install] || Level tracker helps you to track your progress in each skill level. URL: http://tears.family/STABLE/levelapp/
|-
|[[File:LetterApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/rygreg/?sekce=document&klic=letterapp Letter App]''' 0.2 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2585 /appzone 2585]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2585 Install] || Tool to generate custom looking letter images for the role-play purposes. URL: http://tears.family/STABLE/letterapp/
|-
|[[File:RyGREg-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/bagapp/?sekce=document&klic=rygreg RyGReg]''' 0.9.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1947 /appzone 1947]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1947 Install] || Ryzom Guild Registry URL: http://tears.family/STABLE/rygreg/
|-
|[[File:Sluha-icon.png]]|| '''Sluha, the merchant''' - || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1971 /appzone 1971]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1971 Install] || DISFUNCT! Trading with a nomad merchant traveling around Atys URL: http://tears.family/DEVEL/sluha/
|}</includeonly>
<noinclude>
This template displays the table of [[User:Moniq/OOC|Moniq's Apps]] information table. 
== Usage ==
<code><nowiki>{{Moniq's Apps}}</nowiki></code> 
 
which gives: 
{{Moniq's Apps}}
[[Category:User Templates]]</noinclude>

Apps/Letter App

2022-03-29T14:22:23Z

Moniq: /* Introduction */ target URL update

<noinclude>{{Trad
|DE = Apps/Letter App |DEs= 5
|EN = Apps/Letter App |ENs= 0
|ES = Apps/Letter App |ESs= 5
|FR = Apps/Letter App |FRs= 4
|RU = Apps/Letter App |RUs= 5
|H = 1
|palette=
|ref=
|com=
}}{{Clear}}</noinclude>{{TOCright}}<center>[[File:LetterApp-icon.png|64px]]</center>

==Introduction==
[[Apps/Letter App|Letter App]]v 0.2 is a tool, buit by [[User:Moniq|Moniq]], to generate custom looking letter images for role-play purposes. 

*[https://app.ryzom.com/index.php?action=add_user_app&app_id=2585 Install Letter App] in your [[Appzone bar]]
*Launch Letter App:
**''In-Game'': <code>/appzone 2585</code> in command line (chat).
** ''From Appzone'': https://app.ryzom.com/index.php?action=launch_app&appid=2585
** direct URL: http://tears.family/STABLE/letterapp/
* [http://tears.family/STABLE/rygreg/?sekce=document&klic=letterapp Letter App “built-in” Help]
 
{{LetterApp
| letter=548efb6b1630c14faa0ea5735d9fbb9b288ead01
| lang=en
| align=center
| width=200}}

== Letter App User Help ==
:''Note'': This part is a wiki port, with slight Layout changes of the ''[http://beta.kdyne.net/rygreg/STABLE/rygreg/?sekce=document&klic=letterapp%20Letter%20App “built-in” help page]''
<poem> This application allows you to generate letter images with specified background and font for use in role-play. It is based on avatar characteristics and using data managed by Bag App, Fame Tracker and Level Tracker.

This application is not meant as replacement for Izam nor other homin communication. It is a tool that allows everyone to create a custom letter image to use in role-play. The idea was to have a tool where you can put a text, set parameters and get a forum / Izam code you can use.

Another aspect of the application is that your options are based on your character data. ''Available letter medium/font/colour options are based on achieved skill levels or currently owned items''.</poem>

=== Drafts ===
[[File:Letterapp Drafts.png|300px|center]]
<poem> ''[[#Drafts|Drafts]]'' section is where a letter composing starts. You can create new letters here by creating new draft (cilck on "'''ADD'''" top right of the window). Each draft has various settings you can set to customize final letter. First of all you need to specify a draft name and the future letter recipient.
:— '''''Draft name''''' is a mandatory option, in case you will leave this setting empty the system will use previous name or will automatically generate a new name based on current date and time.
:— '''''Recipient''''' is optional setting where you can put a homin name you wish to address your letter for. In case you will leave this option empty, everyone will be able to see the final image. This option is important to if you want to make a letter private. Such letters will be visible for its recipient only.
:— Another very important setting is a letter '''''[[#Medium|Medium]]'''''. You have to select one of available options which will affect following visual options. Every time you change a medium, the draft visual will be set to medium default.
:— The last of draft mandatory options is the textual '''''[[#Content|Content]]'''''. Every draft must have at least one language version of the Role-play text or you will not be able to adjust the visual look nor compose the final letter.
::• '''''RP''''' version is the letter content that will be used to compose the letter image. It should be written strictly IC (In-Character) respecting its use in role-play context. Please remember that the space on the letter is limited by its writing area size and used type and size of message font.
::• '''''OOC''''' version (Out Of Character) is the place where to add any non-RP information or specific details. This information is encapsulated in a spoiler tag for the final letter export code.
:— Once you have set all basic draft options, you can use ''adjustment tools'' to customize draft look. All adjustment options are saved once you change them with the button. You can switch between all available language versions so see how new parameters will affect their look.

Once you are happy with the final look, you can '''''send''''' (publish) your new letter. This operation is not reversible so review carefully the letter visual and its recipient, remember to adjust draft name into new letter name (subject). Once you finish your draft this way, it will be transformed into the final letter. It will be available to read for its recipients since that moment and you will see it in Sent section of the Letter App. You will be redirected to the letter export afterwards.</poem>

=== Sent ===
[[File:Letterapp Send.png|frameless|right|250px]]
This section contains list of all your previously finished letters. You can see details about its parameters, you can display all language version and also open the letter export into forum/Izam code.

You are not allowed to delete old letters and all will remain in your outbox until the recipient will drop it. There is no way how to delete public letters without any recipient.

=== Export ===
This function will build a forum/Izam code that is ready to be inserted into new forum post or message. It includes the final letter version, its content as plain text and also OOC information if any.

In case the letters has a specific recipient, you can also use automatic Izam<ref name="Izam">in-game mail system</ref> sending at bottom of the section. Please note that this will actually redirect you into your Izam application and you need to be authenticated to the Ryzom AppZone already, otherwise an error will occur.

=== Received ===
This is the starting page when you enter the app. 

Here you can find all letter that were finished and you are the recipient. You can view all available language versions or delete the letter from your inbox.

=== Public archive ===
This section is similar to your inbox. The only difference is that it contains all public letters. You can view all available language versions.

=== Medium ===
[[File:Letterapp Media.png|250px|frameless|right]]
This is a list of all items you can use to write on. The list is dynamic and depends on your skill or occupation levels that allows you to obtain more suitable materials. Adopt new occupation and work on your current levels to enable new.

=== Calligraphy ===
[[File:Letterapp Calligraphy.png|250px|frameless|right]]
This is a list of all your calligraphy knowledge you have gained over the time. The list is dynamic and depends on your occupation levels. Improve them or adopt new to discover additional styles of writing.

=== Colours ===
This is a list of all available methods of written information recording and currently available colours. The list is dynamic and depends on which items are available in your bag or in your apartment inventory.

=== Tips ===
[[File:Letterapp Tips.png|250px|frameless|right]]
It might be hard for you to guess which skills and items are involved in processes of this application. Look at following lists that will give you tips which skills to improve or which items to obtain to unlock more application components. Best resources require higher skill or occupation level. In case of Forage and Crafting highest level required is 125. All required items must be placed either in your bag or in your apartment. Requirements that you are currently fulfilling (at least partially) are marked with yellow colour.

===Note ===
In Forum or Izam<ref name="Izam" /> you can also grab the image url; thenInsert the BBCode <code>[img] image URl[/img]</code> in the text of your message; thus with our example:
<nowiki>[img]http://beta.kdyne.net/rygreg/STABLE/letterapp/letter.php?letter=548efb6b1630c14faa0ea5735d9fbb9b288ead01&locale=en[/img]</nowiki>

== Here in EncyclopAtys ==
Url format:
<code><nowiki>http://</nowiki>beta.kdyne.net/rygreg/STABLE/letterapp/letter.php?letter='''548efb6b1630c14faa0ea5735d9fbb9b288ead01'''&locale='''en'''</code>
In '''Red''' are the Letter ID and the language which can be among {de, en, es, fr}. Russian is not yet available sorry 

Due to the very different way wikimedia manages things it is not yet possible to use ''Letter App'' but by grabbing the image url and insert it in an <code><nowiki><img></nowiki></code> html tag such as: 
<code><nowiki><img
src="http://beta.kdyne.net/rygreg/STABLE/letterapp/letter.php?letter=548efb6b1630c14faa0ea5735d9fbb9b288ead01&locale=en"
alt="Letter App example"></nowiki></code>

To make the use of this app easier, and more flexible we have built a '''[[:Template:LetterApp|LetterApp template]]'''. It allows resizing and some alignment abilities <ref>See the [[:Template:LetterApp|LetterApp template]] page for more detailed options description</ref> for better page layout requirements.
There are two ways to use it:
=== Example with complete image url ===
<nowiki>{{LetterApp
| url=http://beta.kdyne.net/rygreg/STABLE/letterapp/letter.php?letter=548efb6b1630c14faa0ea5735d9fbb9b288ead01&locale=en
| align=
| width=200}}</nowiki>
{{LetterApp
| url=http://beta.kdyne.net/rygreg/STABLE/letterapp/letter.php?letter=548efb6b1630c14faa0ea5735d9fbb9b288ead01&locale=en
| align=
| width=200}}

=== Example with Letter ID ===
In this way it is easier to port on different language pages
<nowiki>{{LetterApp
| letter=548efb6b1630c14faa0ea5735d9fbb9b288ead01
| lang=en
| align=floatright
| width=300}}</nowiki>
{{LetterApp
| letter=548efb6b1630c14faa0ea5735d9fbb9b288ead01
| lang=en
| align=floatright
| width=300}}
Post haec Gallus Hierapolim profecturus ut expeditioni specie tenus adesset, Antiochensi plebi suppliciter obsecranti ut inediae dispelleret metum, quae per multas difficilisque causas adfore iam sperabatur, non ut mos est principibus, quorum diffusa potestas localibus subinde medetur aerumnis, disponi quicquam statuit vel ex provinciis alimenta transferri conterminis, sed consularem Syriae Theophilum prope adstantem ultima metuenti multitudini dedit id adsidue replicando quod invito rectore nullus egere poterit victu.

Quod si rectum statuerimus vel concedere amicis, quidquid velint, vel impetrare ab iis, quidquid velimus, perfecta quidem sapientia si simus, nihil habeat res vitii; sed loquimur de iis amicis qui ante oculos sunt, quos vidimus aut de quibus memoriam accepimus, quos novit vita communis. Ex hoc numero nobis exempla sumenda sunt, et eorum quidem maxime qui ad sapientiam proxime accedunt.

Ut enim benefici liberalesque sumus, non ut exigamus gratiam (neque enim beneficium faeneramur sed natura propensi ad liberalitatem sumus), sic amicitiam non spe mercedis adducti sed quod omnis eius fructus in ipso amore inest, expetendam putamus.
 
<noinclude> 
{{Reflist}}
{{Portal|Gameplay|Roleplay}}
[[Category:Apps]]
[[de:Apps/Letter App]] [[en:Apps/Letter App]] [[es:Apps/Letter App]] [[fr:Apps/Letter App]] [[ru:Apps/Letter App]]{{Last version link|Letter App}} </noinclude>

New Tester's Checklist

2021-07-13T21:02:50Z

Moniq: /* Access to necessary chat channels */ new twsrwe's channel name

{{WIP}}
This is a short checklist that you, as a new member of the [[Test Team]], can use to make sure everything is ready.

==Access to necessary chat channels==
Make sure you see all following channels on the Ryzom Chat and that you can speak there. Contact [[User:Tamarea|Tamarea]] to gain access.
* [https://chat.ryzom.com/group/announcements #announcements]
* [https://chat.ryzom.com/group/chat-general #chat-general]
* [https://chat.ryzom.com/group/t-qs_test #t-qs_test]

==Access to all game servers==
Make sure you have installed 3 separate clients to connect different servers and that you can connect to all of them. Contact [[Test_Team#Coordinators|Test Team coordinators]] if you have troubles to configure your clients and [[User:Tamarea|Tamarea]] to gain access.
* Yubo, the development server
* Gingo, the testing server
* Atys, the live server

==Access to Kanboard==
Make sure you are able to see the [https://board.ryzom.com/?controller=BoardViewController&action=show&project_id=51 Test Team Board] and display a task details. Contact [[User:Tamarea|Tamarea]] to gain access.

==Access to the Cloud==
Make sure you are able to see [https://cloud.ryzom.com/f/1355 Test-Team] folder on Ryzom Cloud including subfolders, make sure you can read files, mainly PADs. Contact [[User:Tamarea|Tamarea]] to gain access.

==Account on Wiki==
Make sure you have a valid account on the Ryzom Wiki and that you have added yourself into the [[Test_Team#Testers|list of testers]]. Contact [[User:Zorroargh|Zorroargh]] to create account.

{{Portal|Forge}}
[[Category:Test|Test team]]
[[Category:Tutorials|Test team]]
[[Category:Testing Team]]
[[Category:Ryzom Team]]
[[Category:Test]]
[[Category:Tutorials]]

Testing Team

2021-01-25T00:44:53Z

Moniq: /* How to join? */ +checklist link

{{Trad
|DE =Testing Team|DEs=5
|EN =Testing Team|ENs=0
|ES =Testing Team|ESs=5
|FR =Testing Team|FRs=2
|RU =Testing Team|RUs=5
|H =
|palette=Grey
}}
[[File:Ugly kipucka bug.png|400px|right]]
Test team is one of project teams that is focused on testing and re-testing current or new features of the game and related services. The team is being run by its members, mostly volunteers.
= Aim of the group =
It might look obvious by the team name, however don't be mislead. Our goal is to...
* provide systematic and complex testing for any other team, project or single developer
* discover and resolve all (possible) issues before a change is published
* track and research unresolved issues discovered internally or reported by players
* cooperate with developers, translators, lorists, designers...

= Who can join? =
Aim of our group may look that we seek mostly advanced users. Yes, being a member of another project team is welcome, however signing the NDA is not required. But, don't be mislead again. We are looking for you, in case you are...
* careful and responsible (because we care about tasks)
* prepared for hard work (because your work does not end by an issue discover)
* playing for some time (because testing will spoil your game experience)
* want to improve Ryzom

= How to join? =
We have a [[The Test Team Handbook|Testers handbook]] that can give you some answers. You will however, sooner or later, end up with contacting [[User:Tamarea|Tamarea]] who will grant you access to team tools and give you further information. In case you have joined the Test Team already, here is a [[New Tester's Checklist]] that summarize all you need to resolve before you really can start.

= Team members =
The team is using the system of roles. It means that, based on your abilities and will, you can occupy various roles in the team. This system tries to join abilities of all team members. Flags in front of each member name indicate preferred language in communication. More information about team roles is described in [[Test Team roles]] article.

== Coordinators ==
Members in this role care about all tasks management withing the team, prepare and evaluate all tests being done, update the Test board and make sure all issues were taken care of. Contact them if you are lost or need to request a testing. You do not need to be a member of any other team but you need to have experience with work of the Test team. Following members usually do the team management, in alphabetical order:
* 🇫🇷 [[User:Ashgan|Ashgan]]
* 🇬🇧 [[User:Moniq|Moniq]]
* 🇫🇷 [[User:Tamarea|Tamarea]]
* 🇫🇷 [[User:Ulukyn|Ulukyn]]

== Testers ==
The most important role in the Test team. You do not need to be member of any other team and you do not need previous experience with work of the team. It is the usual starting role for new volunteers. Following members do the core work, the testing, sorted in alphabetical order:
* 🇫🇷 [[User:Ashgan|Ashgan]]
* 🇬🇧 [[User:Beaujhangles|Beaujhangles]]
* ⁇ [[User:Emiro|Emiro]]
* 🇩🇪 [[User:Lasabo|Lasabo]]
* 🇫🇷 [[User:Margote|Margote]]
* 🇬🇧 [[User:Moniq|Moniq]]
* ⁇ [[User:Nightviper|Nightviper]]
* 🇫🇷 [[User:Tuffgong|Tuffgong]]
* ⁇ [[User:Zarden|Zarden]]
* 🇫🇷 [[User:Steamox|Steamox]]

== Developers ==
[[Development_Team|Developers]] and [[ARK|content creators]] are important part of the Test team. We need to communicate with them and report about finished testing. You need to be a Ryzom / Ryzom Core / Ryzom project developer or a member of either the [[:Category:Animation Team|Animation or the Event team]]. Following alphabetically sorted list of members act in this role:
* 🇩🇪 [[User:SirCotare|Cotare]]
* ⁇ [[User:Daemonixus|Daemonixus]]
* ⁇ [[User:Fohdron|Fohdron]]
* ⁇ [[User:Ikarra|Ikarra]]
* ⁇ [[User:Jayvaraman|Jayvaraman]]
* ⁇ [[User:Nimetu|Nimetu]]
* 🇫🇷 [[User:PtitBill|PtitBill]]
* 🇩🇪 [[User:Riasan|Riasan]]
* 🇫🇷 [[User:SIELA1915|Siela]]
* 🇫🇷 [[User:Ulukyn|Ulukyn]]

== Translators ==
While the team concerns on all issues, we also need to cooperate with [[Translation|translators]]. Obviously, to act in this role, you need to be member of the Translation team. Members in the following alphabetically sorted list do use this role.
* 🇩🇪 [[User:Aileya|Aileya]]
* 🇫🇷 [[User:Margote|Margote]]

== Encyclopatysts and Marketing team ==
Another important members of the team are [[Ryzom_Wiki:About|encyclopatysts]] who work on team or end-user documentation and members of the [[:Category:Communication-Marketing_Team|Communication & Marketing team]] who need to review progress of changes and fixes. It requires you to join the Wiki project or become member of the Communication & Marketing team to act in this role. This is a list of members who are usually act in this role, alphabetically sorted:
* 🇬🇧 [[User:Moniq|Moniq]]
* 🇫🇷 [[User:Tamarea|Tamarea]]

== Artists, designers and lorists==
The team work is also to review and test all interfaces and look for possible troubles. This requires cooperation with an [[Computer_graphics|artist]], [[Level-Design|designers]] or [[:category:Lore Team|lorists]] You have to be member of such team to act in this role. Here is a list of members who act in this role most often, alphabetically sorted:
* 🇩🇪 [[User:Aileya|Aileya]]

<noinclude>
{{clear}}{{Last version link|Testing Team}}
{{Portal|Forge}}
[[Category:Test|Test team]] [[Category:Testing Team]] [[Category:Ryzom Team]] [[Category:Test]] [[Category:Tutorials]]</noinclude>

New Tester's Checklist

2021-01-25T00:39:22Z

Moniq: +WIP;+categories;

{{WIP}}
This is a short checklist that you, as a new member of the [[Test Team]], can use to make sure everything is ready.

==Access to necessary chat channels==
Make sure you see all following channels on the Ryzom Chat and that you can speak there. Contact [[User:Tamarea|Tamarea]] to gain access.
* [https://chat.ryzom.com/group/announcements #announcements]
* [https://chat.ryzom.com/group/chat-general #chat-general]
* [https://chat.ryzom.com/group/t-test #test]

==Access to all game servers==
Make sure you have installed 3 separate clients to connect different servers and that you can connect to all of them. Contact [[Test_Team#Coordinators|Test Team coordinators]] if you have troubles to configure your clients and [[User:Tamarea|Tamarea]] to gain access.
* Yubo, the development server
* Gingo, the testing server
* Atys, the live server

==Access to Kanboard==
Make sure you are able to see the [https://board.ryzom.com/?controller=BoardViewController&action=show&project_id=51 Test Team Board] and display a task details. Contact [[User:Tamarea|Tamarea]] to gain access.

==Access to the Cloud==
Make sure you are able to see [https://cloud.ryzom.com/f/1355 Test-Team] folder on Ryzom Cloud including subfolders, make sure you can read files, mainly PADs. Contact [[User:Tamarea|Tamarea]] to gain access.

==Account on Wiki==
Make sure you have a valid account on the Ryzom Wiki and that you have added yourself into the [[Test_Team#Testers|list of testers]]. Contact [[User:Zorroargh|Zorroargh]] to create account.

{{Portal|Forge}}
[[Category:Test|Test team]]
[[Category:Tutorials|Test team]]
[[Category:Testing Team]]
[[Category:Ryzom Team]]
[[Category:Test]]
[[Category:Tutorials]]

New Tester's Checklist

2021-01-25T00:35:24Z

Moniq: list created

This is a short checklist that you, as a new member of the [[Test Team]], can use to make sure everything is ready.

==Access to necessary chat channels==
Make sure you see all following channels on the Ryzom Chat and that you can speak there. Contact [[User:Tamarea|Tamarea]] to gain access.
* [https://chat.ryzom.com/group/announcements #announcements]
* [https://chat.ryzom.com/group/chat-general #chat-general]
* [https://chat.ryzom.com/group/t-test #test]

==Access to all game servers==
Make sure you have installed 3 separate clients to connect different servers and that you can connect to all of them. Contact [[Test_Team#Coordinators|Test Team coordinators]] if you have troubles to configure your clients and [[User:Tamarea|Tamarea]] to gain access.
* Yubo, the development server
* Gingo, the testing server
* Atys, the live server

==Access to Kanboard==
Make sure you are able to see the [https://board.ryzom.com/?controller=BoardViewController&action=show&project_id=51 Test Team Board] and display a task details. Contact [[User:Tamarea|Tamarea]] to gain access.

==Access to the Cloud==
Make sure you are able to see [https://cloud.ryzom.com/f/1355 Test-Team] folder on Ryzom Cloud including subfolders, make sure you can read files, mainly PADs. Contact [[User:Tamarea|Tamarea]] to gain access.

==Account on Wiki==
Make sure you have a valid account on the Ryzom Wiki and that you have added yourself into the [[Test_Team#Testers|list of testers]]. Contact [[User:Zorroargh|Zorroargh]] to create account.

The Test Team Handbook/4 - On a testing server

2021-01-25T00:08:53Z

Moniq: +link to checklist; fixed header levels;

This document attempt to cover your first steps on one of Ryzom testing servers, with focus on testers. It is expected that you already have access to testing servers and you have successfully configured your clients to be actually able to connect. Consult the [[New Tester's Checklist]] to make sure you didn't forget anything. Following information applies to both testing servers, it is not important if you are on Yubo or Gingo.

==Account characters==
When you log to a testing server for the very first time, all your account slots are empty. It is recommended to create just one or two universal characters that will be always ready and leave other slots empty. Most of testing requires you to have none or just some specific skills and in most cases it is faster to simply create new character on your empty slot (or replace previous) for a test then develop a tool to reset your character or even wait for cool-downs.

When you creating your testing characters, avoid using any real Atys character name. Testing and real accounts are separated however it might bring troubles in the future when for example a character debug is be needed. It also prevents you from confusing which server are you on and which character owns what. Same names requires everyone to pay more attention and you won't to delete your character on wrong server by accident. Your character race or gender is not any important.

==First time on server==
Once you are done with creating your avatar and standing on Silan face to Chiang the Strong, it is time to give your new character some skills. The world of a testing server is, more or less, same as Atys you know. To grind necessary levels is however not needed thanks to various tools you are able to use.

Server accounts have a system of privileges. You will be able to use most of normal testing tools, however some specific applications or commands might require higher privileges than you have. In this case ask on your team/project channel (or on the [https://chat.ryzom.com/group/chat-general #chat-general] channel) so someone else with higher privileges can help you. Following text will tell you how you can adjust various aspects of your character and some basics of your life on a testing server but is not meant to be a manual for tools that you will use.

==In-game tools==
[[File:Appzone beta testing.png|thumb|alt=Beta Testing section of App Zone|Beta Testing section of App Zone]]
First of all we need to make clear which tools will we use. At this moment we have several, more or less, separated applications. Please remember that this part of Ryzom expands widely and may change during the time. In case you have any troubles using it, you find an issue or you want to suggest an improvement contact the specific tool creator please.

===[[File:TT icon command toolbar.png|18px|alt="Command toolbar icon"|left]]Command Toolbar===
[[File:Command toolbar.png|thumb|alt=Command toolbar interface|Command toolbar interface]]
It is a toolbar with various links to other testing and administrative interfaces. By default it is placed on your screen somewhere, unless you made it disappear.
* '''Start:'''
** Execute '''/cmdzone show'''
** Press '''Shift+W''' and start '''Command Toolbar''' application from '''Beta Testing''' section.
* '''Creator:''' [[User:Riasan|Riasan]]
{{clear}}

===[[File:Mp buterfly blue.png|18px|alt="Inky's Tool"|left]]Inky's tool===
[[File:Inkys tool.png|thumb|alt=Inky's tool|Inky's tool]]
This is a compact interface that contains some basic functions mostly related to character allegiance. The tool has a shortcut on the Command Toolbar. Use it to get teleportation related items or zig spawned.
* '''Start:'''
** Execute '''/appzone 2449'''
** Run its shortcut from Command Tollbar (position '''6''')
** Press '''Shift+W''' and start '''Inky's Tool''' application from '''Beta Testing''' section.
* '''Creator:''' [[User:Inky|Inky]]
'''Note:''' Tool creator do not provide any further support nor participate on the project.
{{clear}}

===[[File:Mp batiment noyau maduk.png|18px|alt="Teleport interface"|left]]Teleport interface===
[[File:Teleport interface.png|thumb|alt=Teleport interface|Teleport interface]]
This application is used to quick and free teleportation around the planet. It allows you to use one of fix positions for everyone, use short range landscape teleportation or save and share your own positions. The interface has a shortcut on the Command Toolbar.
* '''Start:'''
** Execute '''/appzone 1356'''
** Run its shortcut from Command Tollbar (position '''8''')
** Press '''Shift+W''' and start '''Teleport interface''' application from '''Beta Testing''' section.
* '''Creator:''' [[User:Riasan|Riasan]]
'''Note:''' Every time you use the teleport interface to move, a command with your current position overwrites your clipboard content.
{{clear}}

==GM island==
This is a secret area in the forest region. Its position is in the Fix list of the Teleport interface and has a link in the Inky's tool. You can find there several additional objects you can interact with. You can contact Riasan about all GM island related tools.

[[File:Gm island red box.png|100px|right|alt=Red Box|Red Box]]
====Red Box====
This object is used to access to various additional tools, items or interfaces and its options change in time by what is needed.

[[File:Gm island pumpkin.png|100px|right|alt=Debug Pumpkin|Debug Pumpkin]]
====Debug Pumpkin====
This pumpking was introduced during development of the Ranger rite and gives you access to various related options like setting allegiance, rite state, reset and so.

[[File:Gm island npc.png|100px|right|alt=NPC on GM island|NPC on GM island]]
====Cult giver NPC====
There are also two NPC who can change you civilization and faction allegiance. However we have more advanced tools now accessible from the Command Toolbar or with Inky's tool.

==Help yourself==
Now it is time to really grow your character. Following list will help you to satisfy all your basic needs:
* To '''get money''', you can use '''Money interface''' from the [[The_Test_Team_Handbook/4_-_On_a_testing_server#Command_Toolbar|Command Toolbar]] (position '''1''') or the feature on [[The_Test_Team_Handbook/4_-_On_a_testing_server#Inky.27s_tool|Inky's tool]] with icon of dappers.
* To '''spawn various or special items''' you can use the '''Spawn interface''' from the [[The_Test_Team_Handbook/4_-_On_a_testing_server#Command_Toolbar|Command Toolbar]] (position '''11''') or various buttons on [[The_Test_Team_Handbook/4_-_On_a_testing_server##Inky.27s_tool|Inky's tool]] (to get generic raw materials, teleport pacts and artifacts or a pet).
* To '''find a specific item sheet ID''' you can use '''All sheet list items''' interface from the [[The_Test_Team_Handbook/4_-_On_a_testing_server#Command_Toolbar|Command Toolbar]] (position '''12''')
* To '''find a specific creature sheet ID''' you can use '''All sheet list creature''' interface from the [[The_Test_Team_Handbook/4_-_On_a_testing_server#Command_Toolbar|Command Toolbar]] (position '''2''')
* To '''rise your skill levels''' and (optionally) learn all action bricks you can use the '''Boost''' interface from the [[The_Test_Team_Handbook/4_-_On_a_testing_server#Command_Toolbar|Command Toolbar]] (position '''4)
* To '''set your allegiance''' you can use the '''Fame tool''' interface from the [[The_Test_Team_Handbook/4_-_On_a_testing_server#Command_Toolbar|Command Toolbar]] (position '''13''', allows you to set allegiance and fame) or options on [[The_Test_Team_Handbook/4_-_On_a_testing_server#Inky.27s_tool|Inky's tool]] (will set your allegiance and adjust your fame automatically) or [[The_Test_Team_Handbook/4_-_On_a_testing_server#Cult_giver_NPC|Cult giver NPC]] on the GM island.
** The [[The_Test_Team_Handbook/4_-_On_a_testing_server#Red_Box|Red Box]] on GM island allows you to set your Marauder rite as done, Inky's tool will give you a Marauder teleportation crystal
** The [[The_Test_Team_Handbook/4_-_On_a_testing_server#Debug_Pumpkin|Debug Pumpkin]] on the GM island allows you to set yourself a Ranger aspirant or a Ranger with various additional options, Inky's tool can spawn you the Ranger Map
* To '''set your fame''' you can use the '''Fame tool''' interface from the [[The_Test_Team_Handbook/4_-_On_a_testing_server#Command_Toolbar|Command Toolbar]] (position '''13''')
* To '''quick heal''' your life, sap, stamina or focus you can use the '''State tool''' from the [[The_Test_Team_Handbook/4_-_On_a_testing_server#Command_Toolbar|Command Toolbar]] (position '''3'''). This way you can also resurrect yourself.
* To '''travel''', besides running, you can use the '''Teleportation interface''' from the [[The_Test_Team_Handbook/4_-_On_a_testing_server#Command_Toolbar|Command Toolbar]] (position '''8''') or spawn yourself teleportation related items using [[The_Test_Team_Handbook/4_-_On_a_testing_server#Inky.27s_tool|Inky's tool]].
** To learn more about current position and the area you can use '''Show Position''' tool from the [[The_Test_Team_Handbook/4_-_On_a_testing_server#Command_Toolbar|Command Toolbar]] (position '''18''')
* To '''toggle camera''' between fly and inside your avatar body, use '''Free Camera toggle''' from the [[The_Test_Team_Handbook/4_-_On_a_testing_server#Command_Toolbar|Command Toolbar]] (position '''9''')
* To '''start a mission''' by its ID you can use '''Mission helper''' from the [[The_Test_Team_Handbook/4_-_On_a_testing_server#Command_Toolbar|Command Toolbar]] (position '''16''')

==Game mastering==
Sooner or later, how you tester skills will develop, you will face the need of use more powerful tools. The power comes from using commands, knowledge of the system and account privileges. Each server has separated user rights.

===Server privileges===
User accounts on each server might have various privileges. The following list contains all server ranks, sorted from lowest (Tester) to highest (DEV). Regular player accounts are never able apply for any privileges.
* ''Inactive accounts''
* ''Free to play player (F2P)''
* ''Subscribed player (P2P)''
* Tester
* Event Guide (EG)
* Event Manager (EM)
* Senior Event Manager (SEM)
* Guide (G)
* Senior Guide (SG)
* Veteran Guide (VG)
* Game master (GM)
* Senior Game Master (SGM)
* Developer (DEV)
'''Note:''' Understand the list as to be simplified representation of server hierarchy, not to exactly describe server privileges

===Useful information and tools===
There are some external documents and 3rd party tool links that may be helpful or help you with understanding and use of advanced abilities.

====[https://ryzomcore.atlassian.net/wiki/spaces/RC/pages/19365937/Shard+Commands Shard Commands]====
A list of commands that can be used on running server, including privileges. Created by Ryzom Core project. There is another similar [https://raw.githubusercontent.com/osgcc/ryzom/master/ryzom/server/data_shard/client_commands_privileges.txt List of required privileges for client commands]

====[https://ryzomcore.atlassian.net/wiki/spaces/RC/pages/884873/Ryzom+Service+Architecture Ryzom Service Architecture]====
A Ryzom Core document with that lists and shortly describes all Ryzom server services.

====[[Skill_Tree/Skill_decoding|Skill decoding]]====
A post that explains how are skill keys composed, based on first name's letter.

====[https://api.ryzom.com/ Ryzom API documentation]====
API server with documentation related to public Ryzom APIs.

====[https://ryzomcore.atlassian.net/wiki/spaces/RC/pages/11763715/Ingame+browser In-game browser]====
A simple introduction into capabilities and use of the in-game browser, created by Ryzom Core project. It is also good to follow [https://app.ryzom.com/app_forum/index.php?page=topic/view/24138/ Ingame browser capabilities] thread on Ryzom Forum.

====[https://maps.bmsite.net/sample/builder.html Ballistic Mystix map builder]====
A tool to review and export maps of Atys...

====[https://ofancytext.firebaseapp.com/ Ryzom message coloring tool]====
A simple external tool to generate colour codes for coloring in-game messages (MOTD, crafter's message...)

====[https://atys.wiki.ryzom.com/RyzomNameGenerator/ Ryzom name generator]====
A tool to generate random names suitable for Ryzom. There exists also small [https://app.ryzom.com/app_name_gernerator_api/?race=fyros&gender=male Name generator script] that returns a random name by given parameters via URL

====[http://ryzom.aeness.net/ryzom_word/ Items list]====
Besides build-in sheet browser, which is a part of the Spawn tool as well as Command Toolbar, you can also use external lists of item sheets and names. Another option is to use [http://beta.kdyne.net/rygreg/DEVEL/bagapp/?sekce=itemdb-search search for items] in BagApp database or extract files directly from your client.

====[http://beta.kdyne.net/rygreg/DEVEL/langapp/bbtor.php Blablator API]====
A small LangApp API to provide translations with data based on original [[User:Osquallo|Osquallo]]'s Blablator.

{{Portal|Forge}}
[[Category:Test|Test team]]
[[Category:Tutorials|Test team]]
[[Category:Testing Team]]
[[Category:Ryzom Team]]
[[Category:Test]]
[[Category:Tutorials]]

The Test Team Handbook/6 - Testing report tips

2020-12-25T17:44:44Z

Moniq: -WIP

This document is a collection of tips that are very important for every testing report. Each topic is important and has a reason. It is not possible to write a document that will teach to to be a good tester or that cover all situations that can occur. These are some highlighted important points, however your personal effort and will is the second and not less important part of your work.

=Report into latest PAD=
As a tester, do all your reports into the latest [[File_formats#The_.pads|Testing PAD]] related to a task you are working on. In case the task includes more than one PAD link, always use the latest. There exists a [https://cloud.ryzom.com/f/36218 self-explaining PAD example] as well as a [https://cloud.ryzom.com/f/36039 PAD with some basic help] about PAD organization. The actual form of each Testing PAD is fully up to the current Test guide (a coordinator who manages the current test) however all PADs will be similar because of need to track similar information.

In case that the task has no PAD but the testing is open (very rare situation), do your report directly into the task comments.

=Provide testing environment details=
This is the most important and essential information you provide. Your current character name that was used for testing is not that important and might be useful only in case when a developer needs to review database details related to it. Much more important is to let us know:
* '''Tester name''' - the name that you are using in the Test Team. Not all might be clear from your report and a coordinator might need to talk about details with you.
* '''Platform''' - your operating system name and version including information if it is 32 or 64 bit. Some issues might be platform specific for various reasons.
* '''Language''' - your Ryzom client locales you have used during your testing. Some issues might be language specific for various reasons.
Besides these there might be some specific information needed for a specific testing (for example desktop screen resolution). All these information are usually stored in '''Testers''' section of the PAD. In case that you use various combinations remember to list them all and mention if any discovered issue applies to all or just some of those combinations.

=Read instructions carefully=
Every testing PAD usually has a section with general '''Description'''. You will find there some details about the change you are testing and, optionally, details about known issues, fixed issues, possible rewards, general mechanics of the change or debug/tester tools related to your testing.

Another very important section is '''Instructions''' where you will find more detailed information about which character you need to prepare for the testing, optionally with tips how to do it, and usually a list of things that we need to test. Your work should however not stop here.

=Provide date and time of your testing=
All your reports, questions and feedback go to '''Reports''' section. Always start new report with date and time when the testing was performed, including time zone. This is important for several reasons:
* Actively developed things might change in time and we might need to know if your report was done before a specific change or after
* Server might have technical difficulties by the time of your report and some discovered issues might not be directly related to the task

=Ask if you are lost=
No one knows everything. In case you do not understand the matter of a change, feature mechanics is not clear or in case you have discovered a behaviour that is not covered by the PAD instructions, ask. Every task has a developer mentioned in the PAD and also as a tag sticker on the task. Every opened test has also a Test guide, a coordinator who takes care of the current test. Ask them for details. We all work to make Ryzom better so you should not hesitate to also ask directly on the [https://chat.ryzom.com/group/t-test #t-test] channel.

=Report everything=
Yes, you should reflect all topics in Instructions, but it is also important if you can provide all possible related details you can. Your report should describe what and how you did perform the test and all related circumstances. Describe your activity, especially in case you discover an issue. Be ready to take and provide screenshots along with your report or record a video that captures whole situation. Read [[Making evidence]] article for help with how to do that.

Your report should also be partially a feedback for the Developer or the Test guide and do not hesitate to suggest better solutions for certain situations. Think the player way:
* Think about what players will experience with the feature
* Think about troubles they might have using the feature alone and in combination with other game mechanics
* Keep in mind that players might have limitations (language barriers, colour blindness, disablement...)
* Keep in mind that players might not be as experienced as you are

=Keep eye on your work=
Your work do not end with nice shiny report full of images. Come back in few days and review if your report was reviewed and all issues noted in '''Issues''' section. Ask coordinators and developers about progress. Repeat your questions in case you did not get any answer, either in the PAD or in the chat.

Do not be lazy to prepare new character and repeat your testing. Within one report (testing session) to examine and fully describe discovered issues, but also after a progress. Come back and re-test everything, provide new report reflecting latest changes. Confirm issues discovered by others, confirm issue fixes. You have the intelligence, experience and creativity. That is why we need you. Otherwise a machine could do your work.

=Break testing servers but be discreet on Atys=
When testing on Yubo on Gingo, always look for ways how to break or exploit things. Do not hesitate to do. Better break a testing server then let players to do with Atys. And don't be naive to think players will not try. Play stupid, look for ways how to use things the unexpected way. Combine things even when it looks pointless. Damage feature configuration file. Misuse the user interface. Does it ask for number? Input string. Does it expect you to click a link or button? Reload the window few times. Break it.

Absolutely different situation is when testing on Atys. Do your testing but always mind regular players who came to enjoy the game. In case you have suspicions that something might affect others...
* Do a similar test on Gingo first
* Consult it with developers as next
You should always be inconspicuous and you should definitely avoid doing following things:
* Do not spoil details to pubic, let players have fun and discover things themselves
* Do not bother other players, let them enjoy game features and do not, for example, occupy place/game
* Do not use exploits for other reasons then re-testing (or you will get ban)

{{Portal|Forge}}
[[Category:Test|Test team]]
[[Category:Tutorials|Test team]]
[[Category:Testing Team]]
[[Category:Ryzom Team]]
[[Category:Test]]
[[Category:Tutorials]]

Test Team roles

2020-12-25T17:44:22Z

Moniq: /* Choose a server */ column names changed

{{WIP}}
The team is using the system of roles. It means that, based on your abilities and will, you can occupy various roles in the team. This system tries to join abilities of all team members.

=Theory=
Besides testers themselves, the [[Test Team]] also consists of many members who participate in other Ryzom teams. This and the matter of the team work makes it a place where a cooperation is highly needed. Most of team members are however volunteers and it would be unproductive to stick each member with only one position. That is the reason why we use a system of roles.

* [[#Coordinators|Coordinators]], who coordinate the team
* [[#Testers|Testers]], who perform all testing
* [[#Developers|Developers]], who fix discovered issues
* [[#Translators|Translators]], who fix discovered translation issues
* [[#Encyclopatysts_and_Marketing_team|Encyclopatysts and Marketing team]], who document changes and publish news
* [[#Artists.2C_designers_and_lorists|Artists, designers and lorists]], who fix discovered visual issues and provide background information

Each team member can temporarily act in any role he or she want, in case he meets its requirements, and his or her work emerge from the current role. This also means that different roles focus on different tasks and information. Roles are not permanent and you can switch it any time you want. It is not needed to tell others what role do you actually act in, make your decision and do what is needed. This might be a little confusing, that is why following chapters give you basic overview about tasks of each role.

=Testers=
This chapter describes how to start with a new testing from a tester's perspective. It is expected that you have [[The_Test_Team_Handbook/3_-_Setting_up_connection_to_non-public_Ryzom_servers|set up testing servers]] already (for testing on Yubo ang Gingo) and that you are a bit [[The_Test_Team_Handbook/4_-_On_a_testing_server|familiar with working on testing servers]]. Your work will mainly include:
* Participating on currently opened tests
* Re-testing issues reported by players or other Ryzom team members
* Testing for other Ryzom team members on-demand

While re-testing reported issues requires you own effort and testing on-demand is initiated by other member, regular testing starts on the [[The_Test_Team_Handbook/5_-_Test_board_organization|[Team] Test board]] on the Kan Board. There you can find all active tasks of the team. Following steps will help you to find a test you can do.

==Choose a server==
There are three columns where to look for a test you can do.
* '''Testing on Yubo''' for tests situated on the developers server
* '''Testing on Gingo''' for tests situated on the testing server
* '''Testing on Atys''' for tests opened for live server.
Choose one column and your testing will be placed on corresponding server.

==Choose a task==
Review tasks in the selected column. Priority is set by its position, so tasks on top are more important than those at bottom. Task colour indicates its state, if it is green, the test is running. In case there are some issues discovered already, the task is orange and you should know that the testing round might be closed soon. Find a task that you want to try and open it by clicking.

==Start working==
When you open a task details there is a lot of component and features that are not necessary to perform a test. You should however pay attention to:
* '''Description''' where you can find some overall details
* '''External links''' where you will find links to Testing PAD and other related external documents
* '''Comments''' where some additional task details might be placed
Most of testing tasks contain link to one or more Testing PADs, usually called as ''PAD (<server_name>)'' and listed in '''External links''' section. Find a PAD corresponding to the chosen server and open it. It includes all necessary details and all your reports will go to that Testing PAD. The actual form of the Testing PAD is fully up to the Test Guide. All PADs from previous testing are linked here as ''Archive PAD <date> (<server name>)'' and every newer PAD replaces previous document including all issues opened by that time. Some help with Testing PAD organization can be found in the [https://cloud.ryzom.com/f/36039 PAD help document] or look at self-describing [https://cloud.ryzom.com/f/36218 example PAD].

Please read [[The_Test_Team_Handbook/6_-_Testing_report_tips|Testing report tips]] to know more about what a tester's work covers.

===Tasks without a PAD===
Some minor tests might not have own testing PAD. In that case the task description should contain all necessary details and you put your testing report into the task Comments.

=Developers=
This chapter describes details useful for developers who would like to work on fixing found issues or unblocking testing tasks. In case you need the Test team to perform new testing, follow the [[How to request new testing]] article please. You need to be a [[Development_Team|Ryzom]] / [http://www.ryzomcore.com/ Ryzom Core] / [[Forge_Portal/Projects|Ryzom project]] developer (for example [[ARK]] team) or a member of either the [[Animation team|Animation]] or the [[Event team]]. Your main work in the team includes:
* Request new tests
* Provide testing tools and necessary details
* Solve known issues

==Choose a server==
First you need to choose a server you will work with. Tasks that being prepared for testing on a server are stored in columns on left to server one. '''Waiting for Yubo''' column contains tasks that will continue to testing on server Yubo, '''Waiting for Gingo''' being solved on Gingo server and '''Waiting for Atys''' are going to be (re)tested on Atys.

==Choose a task==
There are two types of board columns you should focus on:
===Non-Tester columns===
'''Blocked for Yubo''', '''Blocked for Gingo''' and '''Blocked for Atys'''. Here are new and troublesome tasks stored and those tasks are not in active testing at the moment. All such tasks are usually yellow (new) or orange (troublesome). Look for tasks with one of following tags on:
* '''⏳ patch''', orange tag, a task that needs to be patched to server first, to enable latest changes and fixes
* '''Clarify first''', yellow tag, for tasks that requires a discussion or more details
* '''Bugs reported''', orange tag, a task with reported issues to be fixed
* '''Bugs reported on Atys''', pink tag, a task with reported issues on Live server to be fixed

===Tester columns===
'''Testing on Yubo''', '''Testing on Gingo''' and '''Testing on Atys'''. All tasks here are currently in the testing. Look for tasks with orange '''Bugs reported''' tag on. Remember that in this case you affect actually running test, be careful and cooperative. Once you find a suitable task, open its details.

==Start working==
When you open a task details there is a lot of component and features that are not necessary for work of a developer. You should however pay attention to
* '''Description''' where you can find some overal details
* '''External links''' where you will find links to other related external documents
* '''Comments''' where some additional task details might be placed
In case the task is not being currently tested, all known issues should be listed as sub-tasks. Assign the sub-task in case you wish to start working on it.

===Tasks with a PAD===
Review current reports and issues in the appropriate Testing PAD (link to be found in External links section). Research a possibility to fix or clarify each reported issue and leave a note in the PAD (along with date and time) once there is any change you perform or you know about (fix, change, additional related details...). Do not mark issues as fixed, wait testers to confirm the fix. Some help with Testing PAD organization can be found in the [https://cloud.ryzom.com/f/36039 PAD help document] or look at self-describing [https://cloud.ryzom.com/f/36218 example PAD].

===Tasks without a PAD===
Some minor tests might not have own testing PAD. Research a possibility to fix or clarify each reported issue and leave a comment about any change you perform (fix, change or additional related details you know). Wait testers to confirm the fix.

=Translators=
Following chapter describes how can members of the Translation team get involved in testing and help solve translation issues. Translators can find a work in almost all parts of the testing process, however more right the task is placed on the board, more complete the change is. It is not common, but members of the Translation team can also request the Test team to perform a testing focused on translations, to look for missing strings or any string related issues like text over-floating and incorrectly encoded strings. In such case please read [[How to request new testing]] article. You need to be a member of the [[Translation|Translation team]] to act in this role. Your work is based on discovered translation issues and will mainly include:
* Fixing known translation issues
* Help testers
* Confirmation

==Choose a server==
First you need to choose a server. There is usually not much to do on Yubo while changes are in early stages there and it can significantly change before it is fully developed and used strings are final. Your best options are to focus on Gingo, where a testing before release is done or Atys where we hunt for missing or wrong translations.

==Choose a task==
Depending on target of your work, you focus on different board columns:

===Management columns, Blocked for Gingo and Blocked for Atys===
Here are new and troublesome tasks stored and those tasks are not in active testing at the moment. Look for tasks with purple Translation issue tag. You can help by fixing wrong or missing translations or by investigating why it is not possible to fix the translation.

===Testing columns, Testing on Gingo and Testing on Atys===
All tasks here are currently running a test. Look for tasks with purple Translation issue tag. You can help by taking care of newly discovered translation issues and giving support to testers in related questions. Some tasks also needs to verify translation issues on Atys. Remember that in this case you affect actually running test, be careful and cooperative. Do all your reports into the latest PAD and remember to mention date and time.

==Start working==
Each task supposed to have a minor issue subt-ask you can assign (if there are any known translation issues), however specific details are part of the latest Testing PAD usually called as ''PAD (<server_name>)'' and listed in '''External links''' section. Find a PAD corresponding to the chosen server and open it. All necessary details and all your reports will go to the Testing PAD. The actual form of the Testing PAD is fully up to the Test Guide. All PADs from previous testing are linked here as ''Archive PAD <date> (<server name>)'' and every newer PAD replaces previous document including all issues opened by that time.

===Fixing known translation issues===
Review all known translation issues and fix as many as possible. If there is a case of string that you are unable to fix as a translator, please investigate reasons. Once your work is done, please add a summary comment with all details into latest Testing PAD so the Test Guide can update the upcoming test or progress the task.

===Help testers===
Testers might have questions related to currently missing strings or other things related to translation. Review the latest Testing PAD and help to resolve those issues or open discussion directly on team chat.

===Confirm issues on Atys===
There might be translation issues that need to be confirmed on Atys. If you have power or suitable character on Atys, please join the test opened on Atys in role of a Tester and verify what is needed along the current Testing PAD.

=Encyclopatysts and Marketing team=
Following text describes what should members of those teams focus on at the Test board in case they collect information for the upcoming release notes. Also members of the Project Ryzom Wiki can start to create documentation based on Testing PAD and task details.It requires you to join the [[Ryzom_Wiki:About|Ryzom Wiki project]] or become member of the [[:Category:Communication-Marketing_Team|Communication & Marketing team]] to act in this role. Your work mainly includes:
* Create new documentation
* Update existing documentation
* Prepare patch notes

==Choose a server==
While Yubo is a testing server for purpose of development, there is nothing to find about completed changes. Important testing is being done on Gingo, all passed tasks approve a change to be released later on Atys. Also tasks being currently tested on Atys itself might give you information about latest bug fixes. You will also meet tasks that correspond to already published changes, however there are issues to solve and the Test team was unable to close those tasks yet.

==Choose a task==
There are two main columns you should choose tasks from:
* '''Blocked for Atys''', where all tasks that successfully passed testing on Gingo server are. These changes are ready to release or being tested on live server, from point of view of the Test team. Look for new tasks (yellow) that has arrived from Gingo or been fixed on Atys. Remember that Orange coloured tasks have some work to be done so even your documentation might not be complete before all is solved.
* '''Done''', where all completed tasks come at the end of own lifetime. These changes were re-tested on Atys and confirmed to be working as expected.
Once you find a suitable task, open its details.

==Start working==
When you open a task details there is a lot of component and features that are not necessary for work of a translator. You should however pay attention to
* '''Description''' where you can find some overal details
* '''External links''' where you will find links to other related external documents
* '''Comments''' where some additional task details might be placed

===Tasks with a PAD===
Review current reports and issues in the appropriate Testing PAD (listed in External links section) to see details about the change. Base your documentation on task description, task comments and latest Testing PAD details. Some help with Testing PAD organization can be found in the [https://cloud.ryzom.com/f/36039 PAD help document] or look at self-describing [https://cloud.ryzom.com/f/36218 example PAD].

===Tasks without a PAD===
Some minor tests might not have own testing PAD. Base your documentation on details in task description and comments.

=Artists, designers and lorists=
Members in this role do not actively participate on the team work, however their abilities are very important in some specific situations. The Test Team might discover missing or broken objects, graphics or design issues, need to clarify details along the Lore or, with your cooperation, suggest solutions for troublesome situations. Our goal is a good player experience after all. You have to be member of an [[Computer_graphics|artist]], a [[Level-Design|design]] or a [[Lore team|lore]] team team to act in this role.

=Coordinators=
Being a team coordinator is the most complicated role, because it includes all the management work. Management of task on the board, creating and evaluating of tests, keeping eye on known issues and communication with other teams represented by team members in roles described above. You need to be experienced with work of the team. It would be hard to describe all within this article so please read the [[Being a Test Team Coordinator]] article.

{{Portal|Forge}}
[[Category:Test|Test team]]
[[Category:Testing Team]]
[[Category:Ryzom Team]]
[[Category:Test]]
[[Category:Tutorials]]

The Test Team Handbook/5 - Test board organization

2020-12-25T17:34:25Z

Moniq: /* Theory */ column names changed

{{Trad
|DE =The Test Team Handbook|DEs=5
|EN =The Test Team Handbook|ENs=0
|ES =The Test Team Handbook|ESs=5
|FR =The Test Team Handbook|FRs=5
|RU =The Test Team Handbook|RUs=5
|H =
|palette=Grey
}}
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
[[File:Test board diagram.png|thumb|alt=Test board process diagram|Test board process diagram]]
This document describes details how tasks on the Test team board are organized.

=Theory=
The board divides whole process into seven steps, with progress from left to right. Odd columns are meant for management and '''Non-Testers''' in the team. Every other column involves testing and is meant for '''Testers'''.

Every task starts in either '''Waiting for Yubo''', '''Waiting for Gingo''' or '''Waiting for Atys''' column. It determines on which server the testing is initially placed. If the task progress (pass all server testing) it moves to right to next server or to end its lifetime as completed in the '''Done''' column.

The task remains "on server" and undertake one or more Test rounds/sessions until the all known or newly discovered issues are solved. The board organization use five main settings to indicate task details to all team members no matter of the current role.
* column on the board - how is overall task progress
* task position in column - priority within the current column
* task colour - general state indication: new (yellow), ok (green), troubles (orange), WIP (grey)
* tag stickers - various additional symptoms of the task
* deadline - the latest date by which the task must be analyzed
 
 
[[File:Tteam task elements.png|center|alt=Test Team board elements description]]
 
<center>''Board task elements''</center>

=Board users=
The work in the Test team is based on team members roles. Based on your current role you have chosen, you pay attention to different parts of the board and operate on different task base. The team itself consists of different type of Ryzom team members, pure testers who look for a running test, translators who work on strings, wiki project members who document changes, marketing team members who wants news for public, event team members who prepare games or scenes and developers who maintain the code. All of them can be, basically, divided into two groups.
* Testing, members who look for opened testing and its details
* Management members who manage tasks between testing

Team members accept (use) different roles while working in the Test team. Your first step should be to tell yourself, what would you like to do with the board now. Based on that, you pay attention to different task details and different parts (columns) of the board:
*'''For Testing:'''
**Testing on Yubo (2nd)
**Testing on Gingo (4th)
**Testing on Atys (6th)
*'''For Management:'''
**Waiting for Yubo (1st)
**Waiting for Gingo (3rd)
**Waiting for Atys (5th)
**Done (7th)

After you open a desired task, based on your role you pay attention to different task details.
* For Testing, usually testers or translators performing a testing, look for latest Testing PAD. You will find there all details related to current running test.
* For Management, use task description/comments to provide task details, external links to add all related documents and sub-tasks to review and manage opened task issues.
Some more about work in the Test team by various roles is described in [[Test Team roles]] article.

=Columns (task progress)=
The theory is that a new testing task travels during its lifetime from left to right when progress and right to left when troublesome. After each testing round or session it is decided if the task is ready to progress (move right on the board) or if there is more work on it (move left on the board).

==Waiting for Yubo==
This column contains new or actually closed tasks that will continue with testing on the Yubo server. It is a place where:
* Yubo task management should be done here (yellow or orange colour)
* developers can create new tasks for the Testing team with target on Yubo server
* translators can review translation issues found during testing (low priority due early stage)
* where all tests with issues return after testing on Yubo is closed
Before such task can continue for new testing on Yubo, a new test must be prepared. That means that all issues must be solved, all patches applied and all problems discussed.

==Testing on Yubo==
This column contains all opened tests on the Yubo server. It is a place where:
* active testers from the Test team should look (green and orange colours)
* all currently opened tests on Yubo server are placed
* non-testers can optionally review running tests here to interact with testers on PAD base (orange colour)

==Waiting for Gingo==
This column contains new or actually closed tasks that will continue with testing on the Gingo server. It is a place where
* Gingo task management should be done here (yellow or orange colour)
* developers can create new tasks for the Testing team with target on Gingo server
* translators can review translation issues found during testing
* where all tests with issues return after testing on Gingo is closed
* where all successful tests on Yubo server come (yellow colour)
Before such task can continue for new testing on Gingo, a new test must be prepared. That means that all issues must be solved, all patches applied and all problems discussed.

==Testing on Gingo==
This column contains all opened tests on the Gingo or Atys BETA server. It is a place where:
* active testers from the Test team should look (green and orange colours)
* all currently opened tests on Gingo or Atys BETA servers are placed
* non-testers can optionally review running tests here to interact with testers on PAD base (orange colour)

==Waiting for Atys==
This column contains new or actually closed tasks that will continue with testing on the Atys server. It is a place where
* non-testers should do a management of tasks that belong to Atys (yellow or orange colour)
* developers can create new tasks for the Testing team with target on Atys server
* translators can review translation issues found during testing
* where all tests with issues return after testing on Atys is closed
* where all successful tests on Gingo server come
Before such task can continue for new testing on Atys, a new test must be prepared. That means that all issues must be solved, all patches applied and all problems discussed.

==Testing on Atys==
This column contains all opened tests on the Atys server. It is a place where:
* active testers from the Test team should look (green and orange colours)
* all currently opened tests on Atys server are placed
* all currently opened tests on beta Atys server are placed
* non-testers can optionally review running tests here to interact with testers on PAD base (orange colour)

==Done==
This is a column where every task come at the end of its lifetime. Once the parent task is adjusted, testing task can be closed.

=Colours (task state)=
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
[[File:Tteam task issues.png|thumb|alt=Test Team board task with known issues|Test Team board task with known issues]]
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
[[File:Tteam task wip.png|thumb|alt=Test Team board task being adjusted by a coordinator|Test Team board task being adjusted by a coordinator]]
Each task can have one of various colours. This setting represents its state:
* Green marks tasks that are running ok, mainly opened tests and tasks in Done column
** Colour for: Testing
* Orange marks troublesome tasks, running tests with confirmed issues or closed tests with any issues preventing progress
** Colour for: Testing, Management
* Yellow marks new tasks in column, needs to be processed
** Colour for: Management
* Grey is a colour for tasks someone is currently doing management on
** Colour for: Management

=Position (task priority in current column)=
Position of a task in each column tells you how important is a work on it. Higher position inside a column means higher task priority. Please ignore the task Priority settings. It belongs to team managers to set their priority. Optionally you can choose initial priority when the task arrives to new column to tell your priority guess, based on task progress, number and seriousness of issues, overall project priority...

=Tag stickers (task symptoms)=
Each task can have one or more stickers (tags) placed on. It represents main current task "symptoms".

==Colour scheme==
Tag stickers have coloured background to help you get oriented.
* Orange is for (confirmed) issues to solve
* Pink is for (confirmed) issues on Atys
* Purple is for (confirmed) translation issues
* Yellow is for questions
* Green is for running test

==Commonly used tags==
The list is dynamic so you can create any sticker you wish, however it is useful to have some standard list of those everyone should understand.
* '''⏳ patch''' (orange): this task requires a server patch before it can progress or be (re)tested
* '''Bugs reported''' (orange): represents tasks that have any unsolved confirmed issues
* '''Bugs reported on Atys''' (pink): represents tasks that have any unsolved confirmed issues
* '''Translation issue''' (purple): represents tasks that have any unsolved translation issues
* '''Test in progress''' (green): represents that a task testing is in progress
* '''Quick''' (green): represents those tasks that have undemanding testing, it should not consume more than 30 minutes of your time
* '''Clarify first''' (yellow): test details or some aspects of testing/change are not clear and needs to be clarified first before testing can continue
* '''Dev: XYZ''' (no colour): represents a developer who to ask for details or discuss issues

=Deadline (task deadline in current column)=
Applies to open tests only, otherwise ignore. The date and time represents when the test (round) will be closed on server. It is needed to have at least basic testing done completed due the date. Deadlines are important in case you need to prepare the change for upcoming patch or if some specific features will be activated for limited time (running events, bigger tests...).

{{Portal|Forge}}
[[Category:Test|Test team]]
[[Category:Tutorials|Test team]]
[[Category:Testing Team]]
[[Category:Ryzom Team]]
[[Category:Test]]
[[Category:Tutorials]]

Being a Test Team Coordinator

2020-12-25T17:31:52Z

Moniq: /* All issues are resolved */ extended

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience.

Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===It is up to you===
To act as a coordinator is your decision and your responsibility. Mostly everyone can mark an issue as resolved, sometimes by accident, and you will also hear lovely stories about happy future. It works, we did it, it is solved. But it is you who (is going to) lead a test so you should make sure yourself that a subject of testing is actually present and running on a target server and that it is possible to even start the testing.

It is you who must confirm that a fix was really delivered to the game server. By own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions will be saying to testers and if they will be able to test.

It is up to you not to accept issues that actually are not issues and to explain all issue aspects to a developer, translators, lorists. It is your job to properly close all issues and make sure all was resolved or moved to Bugs board. It is your work to notify other related teams and projects about existing issues from their domains or about a task progress.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor issues in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that are not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.
To properly close an issue on the Test team side you need to mark the issue as done on the board as well as in the latest PAD and also mark the PAD record with date, time and details about how the issue was resolved. Fixed and confirmed, transformed, splitted or moved to other issues or other tasks, resolved as not being an issue, simply your summary over the specific issue.

===Make suggestions not decisions===
All the testers feedback and suggestions are most welcome, but always remember that testers are not those who make decisions. This belongs to developers, managers, game designers and lorists, depending on a matter of the problem. Your work is to warn other teams about possible troubles, inconsistency or regression or suggest better solution but not to decide how will a fix be implemented (in case it really fix an issue), how will rules be set or if an information is (lore) valid.

When you manage task issues, always expect that a change can be used by not experienced players with different needs and ideas. Try to consider all as neutral and try to find common game principles in a feature and make sure it is balanced and fair to all players. Think about impact on the current game because developers or manages focused on the task might not see it in relation. Testers are those who experience and use a feature as first.

It is also not up to testers nor coordinators to decide if something is or is not a bug and if it will or will not be fixed. On the other hand you must carefully consider every issue that any of the task testers rise and decide if you will pass the problem to someone who can make a decision or if it is attended or fixed already.

===Relate importance to players not to other issues===
We are basically using three type of issues, red for really serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and not to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations, wrong instructions in Journal and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 5 issues for the fictional task #123:
* '''Combine items to exploit''' - this might look serious, but consider circumstances that allow to use it, consider variations with other items. Consider you might need to clarify the issue first. If still an exploit, it will be red issue.
* '''Missing NPC dialog''' - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that the exploit above might look much more important playes no role. Both have same importance from game-play point of view, because it strongly affects the game experience or balance.
* '''Various missing translations''' - missing translations are usually only orange minor issues unless it causes other troubles like when a player will not get important information for example. Then consider to make them red issue
* '''Wrong instructions in Journal''' - you must to consider if you need to clarify information first, what the instructions supposed to say and what is the creator's intention. In case instructions are really wrong, consider how serious the problem is, just a little typo for minor issue or something serious that will break game experience and is a red issue?
* '''No image with event instructions for neutrals''' - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

===Work never ends===
Even after a task has landed in the Done column, the work is not over. The Test team should know the most about new game changes and you should try to track all issues players have experienced. Do not hesitate to go and test the issue yourself on Gingo and, with respect to players, on Atys.

While the task is still on the Test team board, do not hesitate to move it back and rise new issues to solve. In case the task is already completed, consider contacting the original developer, opening new task on Bugs board or request new testing so the Test team knows current situation on Atys.

In case any task related issue is reported on the Ryzom forum, give your feedback to the player and provide the task number where the issue was added so the player can ask about specific task in the future and we will be able to find the issue and details about its solution.

Being a Test Team Coordinator

2020-12-25T17:26:15Z

Moniq: /* All issues are resolved */ typos

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience.

Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===It is up to you===
To act as a coordinator is your decision and your responsibility. Mostly everyone can mark an issue as resolved, sometimes by accident, and you will also hear lovely stories about happy future. It works, we did it, it is solved. But it is you who (is going to) lead a test so you should make sure yourself that a subject of testing is actually present and running on a target server and that it is possible to even start the testing.

It is you who must confirm that a fix was really delivered to the game server. By own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions will be saying to testers and if they will be able to test.

It is up to you not to accept issues that actually are not issues and to explain all issue aspects to a developer, translators, lorists. It is your job to properly close all issues and make sure all was resolved or moved to Bugs board. It is your work to notify other related teams and projects about existing issues from their domains or about a task progress.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor issues in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that are not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

===Make suggestions not decisions===
All the testers feedback and suggestions are most welcome, but always remember that testers are not those who make decisions. This belongs to developers, managers, game designers and lorists, depending on a matter of the problem. Your work is to warn other teams about possible troubles, inconsistency or regression or suggest better solution but not to decide how will a fix be implemented (in case it really fix an issue), how will rules be set or if an information is (lore) valid.

When you manage task issues, always expect that a change can be used by not experienced players with different needs and ideas. Try to consider all as neutral and try to find common game principles in a feature and make sure it is balanced and fair to all players. Think about impact on the current game because developers or manages focused on the task might not see it in relation. Testers are those who experience and use a feature as first.

It is also not up to testers nor coordinators to decide if something is or is not a bug and if it will or will not be fixed. On the other hand you must carefully consider every issue that any of the task testers rise and decide if you will pass the problem to someone who can make a decision or if it is attended or fixed already.

===Relate importance to players not to other issues===
We are basically using three type of issues, red for really serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and not to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations, wrong instructions in Journal and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 5 issues for the fictional task #123:
* '''Combine items to exploit''' - this might look serious, but consider circumstances that allow to use it, consider variations with other items. Consider you might need to clarify the issue first. If still an exploit, it will be red issue.
* '''Missing NPC dialog''' - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that the exploit above might look much more important playes no role. Both have same importance from game-play point of view, because it strongly affects the game experience or balance.
* '''Various missing translations''' - missing translations are usually only orange minor issues unless it causes other troubles like when a player will not get important information for example. Then consider to make them red issue
* '''Wrong instructions in Journal''' - you must to consider if you need to clarify information first, what the instructions supposed to say and what is the creator's intention. In case instructions are really wrong, consider how serious the problem is, just a little typo for minor issue or something serious that will break game experience and is a red issue?
* '''No image with event instructions for neutrals''' - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

===Work never ends===
Even after a task has landed in the Done column, the work is not over. The Test team should know the most about new game changes and you should try to track all issues players have experienced. Do not hesitate to go and test the issue yourself on Gingo and, with respect to players, on Atys.

While the task is still on the Test team board, do not hesitate to move it back and rise new issues to solve. In case the task is already completed, consider contacting the original developer, opening new task on Bugs board or request new testing so the Test team knows current situation on Atys.

In case any task related issue is reported on the Ryzom forum, give your feedback to the player and provide the task number where the issue was added so the player can ask about specific task in the future and we will be able to find the issue and details about its solution.

Being a Test Team Coordinator

2020-12-25T17:22:43Z

Moniq: /* Principles */ +principle, order adjusted

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience.

Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===It is up to you===
To act as a coordinator is your decision and your responsibility. Mostly everyone can mark an issue as resolved, sometimes by accident, and you will also hear lovely stories about happy future. It works, we did it, it is solved. But it is you who (is going to) lead a test so you should make sure yourself that a subject of testing is actually present and running on a target server and that it is possible to even start the testing.

It is you who must confirm that a fix was really delivered to the game server. By own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions will be saying to testers and if they will be able to test.

It is up to you not to accept issues that actually are not issues and to explain all issue aspects to a developer, translators, lorists. It is your job to properly close all issues and make sure all was resolved or moved to Bugs board. It is your work to notify other related teams and projects about existing issues from their domains or about a task progress.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor tasks in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that is not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

===Make suggestions not decisions===
All the testers feedback and suggestions are most welcome, but always remember that testers are not those who make decisions. This belongs to developers, managers, game designers and lorists, depending on a matter of the problem. Your work is to warn other teams about possible troubles, inconsistency or regression or suggest better solution but not to decide how will a fix be implemented (in case it really fix an issue), how will rules be set or if an information is (lore) valid.

When you manage task issues, always expect that a change can be used by not experienced players with different needs and ideas. Try to consider all as neutral and try to find common game principles in a feature and make sure it is balanced and fair to all players. Think about impact on the current game because developers or manages focused on the task might not see it in relation. Testers are those who experience and use a feature as first.

It is also not up to testers nor coordinators to decide if something is or is not a bug and if it will or will not be fixed. On the other hand you must carefully consider every issue that any of the task testers rise and decide if you will pass the problem to someone who can make a decision or if it is attended or fixed already.

===Relate importance to players not to other issues===
We are basically using three type of issues, red for really serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and not to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations, wrong instructions in Journal and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 5 issues for the fictional task #123:
* '''Combine items to exploit''' - this might look serious, but consider circumstances that allow to use it, consider variations with other items. Consider you might need to clarify the issue first. If still an exploit, it will be red issue.
* '''Missing NPC dialog''' - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that the exploit above might look much more important playes no role. Both have same importance from game-play point of view, because it strongly affects the game experience or balance.
* '''Various missing translations''' - missing translations are usually only orange minor issues unless it causes other troubles like when a player will not get important information for example. Then consider to make them red issue
* '''Wrong instructions in Journal''' - you must to consider if you need to clarify information first, what the instructions supposed to say and what is the creator's intention. In case instructions are really wrong, consider how serious the problem is, just a little typo for minor issue or something serious that will break game experience and is a red issue?
* '''No image with event instructions for neutrals''' - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

===Work never ends===
Even after a task has landed in the Done column, the work is not over. The Test team should know the most about new game changes and you should try to track all issues players have experienced. Do not hesitate to go and test the issue yourself on Gingo and, with respect to players, on Atys.

While the task is still on the Test team board, do not hesitate to move it back and rise new issues to solve. In case the task is already completed, consider contacting the original developer, opening new task on Bugs board or request new testing so the Test team knows current situation on Atys.

In case any task related issue is reported on the Ryzom forum, give your feedback to the player and provide the task number where the issue was added so the player can ask about specific task in the future and we will be able to find the issue and details about its solution.

Being a Test Team Coordinator

2020-12-25T17:08:31Z

Moniq: /* Principles */ order changed

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience.

Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===It is up to you===
To act as a coordinator is your decision and your responsibility. Mostly everyone can mark an issue as resolved, sometimes by accident, and you will also hear lovely stories about happy future. It works, we did it, it is solved. But it is you who (is going to) lead a test so you should make sure yourself that a subject of testing is actually present and running on a target server and that it is possible to even start the testing.

It is you who must confirm that a fix was really delivered to the game server. By own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions will be saying to testers and if they will be able to test.

It is up to you not to accept issues that actually are not issues and to explain all issue aspects to a developer, translators, lorists. It is your job to properly close all issues and make sure all was resolved or moved to Bugs board. It is your work to notify other related teams and projects about existing issues from their domains or about a task progress.

===Make suggestions not decisions===
All the testers feedback and suggestions are most welcome, but always remember that testers are not those who make decisions. This belongs to developers, managers, game designers and lorists, depending on a matter of the problem. Your work is to warn other teams about possible troubles, inconsistency or regression or suggest better solution but not to decide how will a fix be implemented (in case it really fix an issue), how will rules be set or if an information is (lore) valid.

When you manage task issues, always expect that a change can be used by not experienced players with different needs and ideas. Try to consider all as neutral and try to find common game principles in a feature and make sure it is balanced and fair to all players. Think about impact on the current game because developers or manages focused on the task might not see it in relation. Testers are those who experience and use a feature as first.

It is also not up to testers nor coordinators to decide if something is or is not a bug and if it will or will not be fixed. On the other hand you must carefully consider every issue that any of the task testers rise and decide if you will pass the problem to someone who can make a decision or if it is attended or fixed already.

===Relate importance to players not to other issues===
We are basically using three type of issues, red for really serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and not to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations, wrong instructions in Journal and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 5 issues for the fictional task #123:
* '''Combine items to exploit''' - this might look serious, but consider circumstances that allow to use it, consider variations with other items. Consider you might need to clarify the issue first. If still an exploit, it will be red issue.
* '''Missing NPC dialog''' - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that the exploit above might look much more important playes no role. Both have same importance from game-play point of view, because it strongly affects the game experience or balance.
* '''Various missing translations''' - missing translations are usually only orange minor issues unless it causes other troubles like when a player will not get important information for example. Then consider to make them red issue
* '''Wrong instructions in Journal''' - you must to consider if you need to clarify information first, what the instructions supposed to say and what is the creator's intention. In case instructions are really wrong, consider how serious the problem is, just a little typo for minor issue or something serious that will break game experience and is a red issue?
* '''No image with event instructions for neutrals''' - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor tasks in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that is not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

Being a Test Team Coordinator

2020-12-25T17:04:32Z

Moniq: /* Never trust others */ rewritten, extended

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience.

Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor tasks in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that is not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

===Relate an issue importance to players not to other issues===
We are basically using three type of issues, red for really serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and not to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations, wrong instructions in Journal and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 5 issues for the fictional task #123:
* '''Combine items to exploit''' - this might look serious, but consider circumstances that allow to use it, consider variations with other items. Consider you might need to clarify the issue first. If still an exploit, it will be red issue.
* '''Missing NPC dialog''' - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that the exploit above might look much more important playes no role. Both have same importance from game-play point of view, because it strongly affects the game experience or balance.
* '''Various missing translations''' - missing translations are usually only orange minor issues unless it causes other troubles like when a player will not get important information for example. Then consider to make them red issue
* '''Wrong instructions in Journal''' - you must to consider if you need to clarify information first, what the instructions supposed to say and what is the creator's intention. In case instructions are really wrong, consider how serious the problem is, just a little typo for minor issue or something serious that will break game experience and is a red issue?
* '''No image with event instructions for neutrals''' - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===It is up to you===
To act as a coordinator is your decision and your responsibility. Mostly everyone can mark an issue as resolved, sometimes by accident, and you will also hear lovely stories about happy future. It works, we did it, it is solved. But it is you who (is going to) lead a test so you should make sure yourself that a subject of testing is actually present and running on a target server and that it is possible to even start the testing.

It is you who must confirm that a fix was really delivered to the game server. By own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions will be saying to testers and if they will be able to test.

It is up to you not to accept issues that actually are not issues and to explain all issue aspects to a developer, translators, lorists. It is your job to properly close all issues and make sure all was resolved or moved to Bugs board. It is your work to notify other related teams and projects about existing issues from their domains or about a task progress.

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

===Make suggestions not decisions===
All the testers feedback and suggestions are most welcome, but always remember that testers are not those who make decisions. This belongs to developers, managers, game designers and lorists, depending on a matter of the problem. Your work is to warn other teams about possible troubles, inconsistency or regression or suggest better solution but not to decide how will a fix be implemented (in case it really fix an issue), how will rules be set or if an information is (lore) valid.

When you manage task issues, always expect that a change can be used by not experienced players with different needs and ideas. Try to consider all as neutral and try to find common game principles in a feature and make sure it is balanced and fair to all players. Think about impact on the current game because developers or manages focused on the task might not see it in relation. Testers are those who experience and use a feature as first.

It is also not up to testers nor coordinators to decide if something is or is not a bug and if it will or will not be fixed. On the other hand you must carefully consider every issue that any of the task testers rise and decide if you will pass the problem to someone who can make a decision or if it is attended or fixed already.

Being a Test Team Coordinator

2020-12-25T16:53:56Z

Moniq: /* Relate an issue importance to players not to other issues */ one point rewritten

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience.

Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor tasks in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that is not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

===Relate an issue importance to players not to other issues===
We are basically using three type of issues, red for really serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and not to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations, wrong instructions in Journal and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 5 issues for the fictional task #123:
* '''Combine items to exploit''' - this might look serious, but consider circumstances that allow to use it, consider variations with other items. Consider you might need to clarify the issue first. If still an exploit, it will be red issue.
* '''Missing NPC dialog''' - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that the exploit above might look much more important playes no role. Both have same importance from game-play point of view, because it strongly affects the game experience or balance.
* '''Various missing translations''' - missing translations are usually only orange minor issues unless it causes other troubles like when a player will not get important information for example. Then consider to make them red issue
* '''Wrong instructions in Journal''' - you must to consider if you need to clarify information first, what the instructions supposed to say and what is the creator's intention. In case instructions are really wrong, consider how serious the problem is, just a little typo for minor issue or something serious that will break game experience and is a red issue?
* '''No image with event instructions for neutrals''' - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never trust others===
Always make sure that a fix was actually delivered. Mostly everyone can mark an issue as resolved and also write you a story about happy future but it is you who (is going to) lead a test so you should make sure yourself that the subject of testing is actually present on target server and that it is possible to even start testing. It is you who must confirm that a fix is really part of the game, by own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions say to testers, if they are able to test and if you do not accept issues that actually are not issues.

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

===Make suggestions not decisions===
All the testers feedback and suggestions are most welcome, but always remember that testers are not those who make decisions. This belongs to developers, managers, game designers and lorists, depending on a matter of the problem. Your work is to warn other teams about possible troubles, inconsistency or regression or suggest better solution but not to decide how will a fix be implemented (in case it really fix an issue), how will rules be set or if an information is (lore) valid.

When you manage task issues, always expect that a change can be used by not experienced players with different needs and ideas. Try to consider all as neutral and try to find common game principles in a feature and make sure it is balanced and fair to all players. Think about impact on the current game because developers or manages focused on the task might not see it in relation. Testers are those who experience and use a feature as first.

It is also not up to testers nor coordinators to decide if something is or is not a bug and if it will or will not be fixed. On the other hand you must carefully consider every issue that any of the task testers rise and decide if you will pass the problem to someone who can make a decision or if it is attended or fixed already.

Being a Test Team Coordinator

2020-12-25T16:47:11Z

Moniq: /* Relate an issue importance to players not to other issues */ +bold

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience.

Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor tasks in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that is not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

===Relate an issue importance to players not to other issues===
We are basically using three type of issues, red for really serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and not to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations, wrong instructions in Journal and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 5 issues for the fictional task #123:
* '''Combine items to exploit''' - this might look serious, but consider circumstances that allow to use it, consider variations with other items. Consider you might need to clarify the issue first. If still an exploit, it will be red issue.
* '''Missing NPC dialog''' - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that the exploit above might look much more important playes no role. Both have same importance from game-play point of view, because it strongly affects the game experience or balance.
* '''Various missing translations''' - missing translations are usually only orange minor issues unless it causes other troubles like when a player will not get important information for example. Then consider to make them red issue
* '''Wrong instructions in Journal''' - you consider if you need need to clarify first information that the instructions supposed to say and what is the creator's intention and then in case it is really wrong how serious is the problem is, just a little typo for minor issue or something misleading to be a serious red issue.
* '''No image with event instructions for neutrals''' - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never trust others===
Always make sure that a fix was actually delivered. Mostly everyone can mark an issue as resolved and also write you a story about happy future but it is you who (is going to) lead a test so you should make sure yourself that the subject of testing is actually present on target server and that it is possible to even start testing. It is you who must confirm that a fix is really part of the game, by own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions say to testers, if they are able to test and if you do not accept issues that actually are not issues.

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

===Make suggestions not decisions===
All the testers feedback and suggestions are most welcome, but always remember that testers are not those who make decisions. This belongs to developers, managers, game designers and lorists, depending on a matter of the problem. Your work is to warn other teams about possible troubles, inconsistency or regression or suggest better solution but not to decide how will a fix be implemented (in case it really fix an issue), how will rules be set or if an information is (lore) valid.

When you manage task issues, always expect that a change can be used by not experienced players with different needs and ideas. Try to consider all as neutral and try to find common game principles in a feature and make sure it is balanced and fair to all players. Think about impact on the current game because developers or manages focused on the task might not see it in relation. Testers are those who experience and use a feature as first.

It is also not up to testers nor coordinators to decide if something is or is not a bug and if it will or will not be fixed. On the other hand you must carefully consider every issue that any of the task testers rise and decide if you will pass the problem to someone who can make a decision or if it is attended or fixed already.

Being a Test Team Coordinator

2020-12-25T16:45:48Z

Moniq: /* Relate an issue importance to players not to other issues */ -typo

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience.

Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor tasks in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that is not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

===Relate an issue importance to players not to other issues===
We are basically using three type of issues, red for really serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and not to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations, wrong instructions in Journal and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 5 issues for the fictional task #123:
* Combine items to exploit - this might look serious, but consider circumstances that allow to use it, consider variations with other items. Consider you might need to clarify the issue first. If still an exploit, it will be red issue.
* Missing NPC dialog - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that the exploit above might look much more important playes no role. Both have same importance from game-play point of view, because it strongly affects the game experience or balance.
* Various missing translations - missing translations are usually only orange minor issues unless it causes other troubles like when a player will not get important information for example. Then consider to make them red issue
* Wrong instructions in Journal - you consider if you need need to clarify first information that the instructions supposed to say and what is the creator's intention and then in case it is really wrong how serious is the problem is, just a little typo for minor issue or something misleading to be a serious red issue.
* No image with event instructions for neutrals - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never trust others===
Always make sure that a fix was actually delivered. Mostly everyone can mark an issue as resolved and also write you a story about happy future but it is you who (is going to) lead a test so you should make sure yourself that the subject of testing is actually present on target server and that it is possible to even start testing. It is you who must confirm that a fix is really part of the game, by own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions say to testers, if they are able to test and if you do not accept issues that actually are not issues.

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

===Make suggestions not decisions===
All the testers feedback and suggestions are most welcome, but always remember that testers are not those who make decisions. This belongs to developers, managers, game designers and lorists, depending on a matter of the problem. Your work is to warn other teams about possible troubles, inconsistency or regression or suggest better solution but not to decide how will a fix be implemented (in case it really fix an issue), how will rules be set or if an information is (lore) valid.

When you manage task issues, always expect that a change can be used by not experienced players with different needs and ideas. Try to consider all as neutral and try to find common game principles in a feature and make sure it is balanced and fair to all players. Think about impact on the current game because developers or manages focused on the task might not see it in relation. Testers are those who experience and use a feature as first.

It is also not up to testers nor coordinators to decide if something is or is not a bug and if it will or will not be fixed. On the other hand you must carefully consider every issue that any of the task testers rise and decide if you will pass the problem to someone who can make a decision or if it is attended or fixed already.

Being a Test Team Coordinator

2020-12-25T16:44:09Z

Moniq: /* Testing leadership */ 2 paragraphs

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience.

Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor tasks in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that is not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

===Relate an issue importance to players not to other issues===
We are basically using three type of issues, red for really serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations, wrong instructions in Journal and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 5 issues for the fictional task #123:
* Combine items to exploit - this might look serious, but consider circumstances that allow to use it, consider variations with other items. Consider you might need to clarify the issue first. If still an exploit, it will be red issue.
* Missing NPC dialog - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that the exploit above might look much more important playes no role. Both have same importance from game-play point of view, because it strongly affects the game experience or balance.
* Various missing translations - missing translations are usually only orange minor issues unless it causes other troubles like when a player will not get important information for example. Then consider to make them red issue
* Wrong instructions in Journal - you consider if you need need to clarify first information that the instructions supposed to say and what is the creator's intention and then in case it is really wrong how serious is the problem is, just a little typo for minor issue or something misleading to be a serious red issue.
* No image with event instructions for neutrals - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never trust others===
Always make sure that a fix was actually delivered. Mostly everyone can mark an issue as resolved and also write you a story about happy future but it is you who (is going to) lead a test so you should make sure yourself that the subject of testing is actually present on target server and that it is possible to even start testing. It is you who must confirm that a fix is really part of the game, by own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions say to testers, if they are able to test and if you do not accept issues that actually are not issues.

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

===Make suggestions not decisions===
All the testers feedback and suggestions are most welcome, but always remember that testers are not those who make decisions. This belongs to developers, managers, game designers and lorists, depending on a matter of the problem. Your work is to warn other teams about possible troubles, inconsistency or regression or suggest better solution but not to decide how will a fix be implemented (in case it really fix an issue), how will rules be set or if an information is (lore) valid.

When you manage task issues, always expect that a change can be used by not experienced players with different needs and ideas. Try to consider all as neutral and try to find common game principles in a feature and make sure it is balanced and fair to all players. Think about impact on the current game because developers or manages focused on the task might not see it in relation. Testers are those who experience and use a feature as first.

It is also not up to testers nor coordinators to decide if something is or is not a bug and if it will or will not be fixed. On the other hand you must carefully consider every issue that any of the task testers rise and decide if you will pass the problem to someone who can make a decision or if it is attended or fixed already.

Being a Test Team Coordinator

2020-12-25T16:42:02Z

Moniq: /* Relate an issue importance to players not to other issues */ +colors and little fixes

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience. Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor tasks in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that is not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

===Relate an issue importance to players not to other issues===
We are basically using three type of issues, red for really serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations, wrong instructions in Journal and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 5 issues for the fictional task #123:
* Combine items to exploit - this might look serious, but consider circumstances that allow to use it, consider variations with other items. Consider you might need to clarify the issue first. If still an exploit, it will be red issue.
* Missing NPC dialog - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that the exploit above might look much more important playes no role. Both have same importance from game-play point of view, because it strongly affects the game experience or balance.
* Various missing translations - missing translations are usually only orange minor issues unless it causes other troubles like when a player will not get important information for example. Then consider to make them red issue
* Wrong instructions in Journal - you consider if you need need to clarify first information that the instructions supposed to say and what is the creator's intention and then in case it is really wrong how serious is the problem is, just a little typo for minor issue or something misleading to be a serious red issue.
* No image with event instructions for neutrals - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never trust others===
Always make sure that a fix was actually delivered. Mostly everyone can mark an issue as resolved and also write you a story about happy future but it is you who (is going to) lead a test so you should make sure yourself that the subject of testing is actually present on target server and that it is possible to even start testing. It is you who must confirm that a fix is really part of the game, by own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions say to testers, if they are able to test and if you do not accept issues that actually are not issues.

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

===Make suggestions not decisions===
All the testers feedback and suggestions are most welcome, but always remember that testers are not those who make decisions. This belongs to developers, managers, game designers and lorists, depending on a matter of the problem. Your work is to warn other teams about possible troubles, inconsistency or regression or suggest better solution but not to decide how will a fix be implemented (in case it really fix an issue), how will rules be set or if an information is (lore) valid.

When you manage task issues, always expect that a change can be used by not experienced players with different needs and ideas. Try to consider all as neutral and try to find common game principles in a feature and make sure it is balanced and fair to all players. Think about impact on the current game because developers or manages focused on the task might not see it in relation. Testers are those who experience and use a feature as first.

It is also not up to testers nor coordinators to decide if something is or is not a bug and if it will or will not be fixed. On the other hand you must carefully consider every issue that any of the task testers rise and decide if you will pass the problem to someone who can make a decision or if it is attended or fixed already.

Being a Test Team Coordinator

2020-12-25T16:29:24Z

Moniq: /* Relate an issue importance to players not to other isues */ -typos

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience. Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor tasks in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that is not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

===Relate an issue importance to players not to other issues===
We are basically using three type of issues, red for real serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 4 issues for the fictional task #123:
* Combine items to exploit - this might look serious, but consider circumstances that allow to use it, consider variations with other items. But it is still an exploit and thus will be red issue.
* Missing NPC dialog - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that an exploit above might look much more important, both have same importance from game-play point of view, because it strongly affects the game.
* Various missing translations - missing translations are usually only minor issues unless it causes other troubles (a player will not get important information for example).
* No image with event instructions for neutrals - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never trust others===
Always make sure that a fix was actually delivered. Mostly everyone can mark an issue as resolved and also write you a story about happy future but it is you who (is going to) lead a test so you should make sure yourself that the subject of testing is actually present on target server and that it is possible to even start testing. It is you who must confirm that a fix is really part of the game, by own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions say to testers, if they are able to test and if you do not accept issues that actually are not issues.

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

===Make suggestions not decisions===
All the testers feedback and suggestions are most welcome, but always remember that testers are not those who make decisions. This belongs to developers, managers, game designers and lorists, depending on a matter of the problem. Your work is to warn other teams about possible troubles, inconsistency or regression or suggest better solution but not to decide how will a fix be implemented (in case it really fix an issue), how will rules be set or if an information is (lore) valid.

When you manage task issues, always expect that a change can be used by not experienced players with different needs and ideas. Try to consider all as neutral and try to find common game principles in a feature and make sure it is balanced and fair to all players. Think about impact on the current game because developers or manages focused on the task might not see it in relation. Testers are those who experience and use a feature as first.

It is also not up to testers nor coordinators to decide if something is or is not a bug and if it will or will not be fixed. On the other hand you must carefully consider every issue that any of the task testers rise and decide if you will pass the problem to someone who can make a decision or if it is attended or fixed already.

Being a Test Team Coordinator

2020-12-25T16:27:58Z

Moniq: /* Principles */ +more principles

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience. Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor tasks in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that is not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

===Relate an issue importance to players not to other isues===
We are basically using three type of issues, red for real serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 4 issues for the fictional task #123:
* Combine items to exploit - this might look serious, but consider circumstances that allow to use it, consider variations with other items. But it is still an exploit and thus will be red issue.
* Missing NPC dialog - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that an expliot above might look much more important, both have same importance from game-play point of view, because it strongly affects the game.
* Various missing translations - missing translations are usually only minor issues unless it causes other troubles (a player will not get important information for example).
* No image with event instructions for neutrals - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never trust others===
Always make sure that a fix was actually delivered. Mostly everyone can mark an issue as resolved and also write you a story about happy future but it is you who (is going to) lead a test so you should make sure yourself that the subject of testing is actually present on target server and that it is possible to even start testing. It is you who must confirm that a fix is really part of the game, by own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions say to testers, if they are able to test and if you do not accept issues that actually are not issues.

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

===Make suggestions not decisions===
All the testers feedback and suggestions are most welcome, but always remember that testers are not those who make decisions. This belongs to developers, managers, game designers and lorists, depending on a matter of the problem. Your work is to warn other teams about possible troubles, inconsistency or regression or suggest better solution but not to decide how will a fix be implemented (in case it really fix an issue), how will rules be set or if an information is (lore) valid.

When you manage task issues, always expect that a change can be used by not experienced players with different needs and ideas. Try to consider all as neutral and try to find common game principles in a feature and make sure it is balanced and fair to all players. Think about impact on the current game because developers or manages focused on the task might not see it in relation. Testers are those who experience and use a feature as first.

It is also not up to testers nor coordinators to decide if something is or is not a bug and if it will or will not be fixed. On the other hand you must carefully consider every issue that any of the task testers rise and decide if you will pass the problem to someone who can make a decision or if it is attended or fixed already.

Being a Test Team Coordinator

2020-12-25T16:08:57Z

Moniq: /* Testing leadership */ minor fixes

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board and find the one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience. Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor tasks in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that is not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

===Relate an issue importance to players not to other isues===
We are basically using three type of issues, red for real serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 4 issues for the fictional task #123:
* Combine items to exploit - this might look serious, but consider circumstances that allow to use it, consider variations with other items. But it is still an exploit and thus will be red issue.
* Missing NPC dialog - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that an expliot above might look much more important, both have same importance from game-play point of view, because it strongly affects the game.
* Various missing translations - missing translations are usually only minor issues unless it causes other troubles (a player will not get important information for example).
* No image with event instructions for neutrals - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never trust others===
Always make sure that a fix was actually delivered. Mostly everyone can mark an issue as resolved and also write you a story about happy future but it is you who (is going to) lead a test so you should make sure yourself that the subject of testing is actually present on target server and that it is possible to even start testing. It is you who must confirm that a fix is really part of the game, by own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions say to testers, if they are able to test and if you do not accept issues that actually are not issues.

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

Being a Test Team Coordinator

2020-12-25T16:06:45Z

Moniq: /* New task creation */ typo

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the begining of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board to find one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience. Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor tasks in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that is not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

===Relate an issue importance to players not to other isues===
We are basically using three type of issues, red for real serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 4 issues for the fictional task #123:
* Combine items to exploit - this might look serious, but consider circumstances that allow to use it, consider variations with other items. But it is still an exploit and thus will be red issue.
* Missing NPC dialog - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that an expliot above might look much more important, both have same importance from game-play point of view, because it strongly affects the game.
* Various missing translations - missing translations are usually only minor issues unless it causes other troubles (a player will not get important information for example).
* No image with event instructions for neutrals - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never trust others===
Always make sure that a fix was actually delivered. Mostly everyone can mark an issue as resolved and also write you a story about happy future but it is you who (is going to) lead a test so you should make sure yourself that the subject of testing is actually present on target server and that it is possible to even start testing. It is you who must confirm that a fix is really part of the game, by own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions say to testers, if they are able to test and if you do not accept issues that actually are not issues.

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

Being a Test Team Coordinator

2020-12-25T15:58:32Z

Moniq: /* Principles */ additional principles

{{WIP}}
A team coordinator is a person, who is willing to coordinate the work of others and manage all the boring bureaucracy of the Test team. It requires a lot of additional time, patience and responsibility. Testers will be lazy, developers will lie, marketing will make promises and other teams will have no time for your problems. However, the work must be done somehow. If you think you can help the team in this way, this article will give you some closer looks on principles how your work should look.

It is expected that you understand the process how tasks are being managed on [Team] Test board and you understand why. Your membership in other Ryzom teams and projects can be very helpful, especially membership in the Bugs project that allows you to also manage related issues on Bugs board. You should also be familiar with ways how to [[Making_evidence|make an evidence]] for testing purposes.

==Theory==
In case of the Test team, all the team the work is closely related to team board tasks. The team is requested to perform a testing on a target server, does the job and cares about all discovered issues. There are three main jobs that belong to a coordination and connect all the testing process together, however it is not possible to give you exact points to do. Every task is different so you should be creative within process principles.

===New task creation===
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
This is the being of all tasks. One of team coordinators must create a new task and prepare some initial documentation for a testing. It means that you create new task in Waiting column of the target server, describe all request details like what to test, under which circumstances, background lore information and similar. All the information that is necessary for the future test leader to fully understand the matter of the change. This job is very often done by developers to request a testing and you can read [[How to request new testing]] article that describes this process from opposite side.

You should make sure that all aspects of the change (testing) are clarified and that there are no doubts about any of general questions, for example how high an event reward should be or how long a mission cool-down should take. Remember that the future test leader needs to know as much as possible to prepare valid testing for testers.

===Testing leadership===
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
To lead a testing of a task is the most common job that a coordinator can do. You choose from new (yellow) tasks waiting on the board to find one you want to care about. Review the task changes on the target server to make sure it is running, create a testing PAD with all necessary instructions and do at least quick test yourself. Make sure you provide all necessary instructions for testers, remember that testers might be just volunteers who want to help but have no previous experience. Once the test is completed or when it is not possible to continue in testing, it is your work to evaluate the testing, track all known issues and notify other teams about results. You decide if a task can progress or if it will return.

===Requesting other teams===
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
It is almost rare that a testing will end with no issues and even when it happens, you still need guide the task to finish.

====Task with issues====
In case there are any issues, there are three options how to resolve them:
* Issue is confirmed but not actually an issue - clarify all details with related teams and developers and close it if works as intended
* Issue is confirmed and can be fixed along the testing - pass the issue to the appropriate team to solve
* Issue is confirmed and can't be fixed along the testing - add the issue to the Bugs board at the end of the task lifetime

====Tasks without issues====
Those tasks that have no known issues can progress or be closed. Notify the task developer, team manager, marketing team, translators and/or encyclopatysts at right moment so they can do their work - move the change to next server, complete translation, write documentation for wiki, announce the change, write patch notes... whatever their work is.

==Principles==
The work of a coordinator is not about to certain amount of tasks right or write number of task comments. Make your work to fit current task needs but please follow these principles. Every single one has a reason to exist and will help you to do better job after all.

===All issues are resolved===
Make sure that you track all issues that were discovered during a task lifetime and that all of them are properly resolved before that task is closed.
* Issues that can be clarify must be clarify before end of testing, because it might lead to additional other issues that will be consequent of such issue.
* Issues that can be solved withing the testing task must be fixed, re-tested and the fix confirmed before the task can progress. The only exception are minor tasks in case of progress from one server to another, related to features that are not fully completed yet. Such issue can remain open but still must be properly resolved at the end of the task lifetime.
* Issues that is not possible to fix withing the task, usually bugs related to a system functions on which the change is based on, must go to the Bugs board and then be closed within the Testing task.

===Relate an issue importance to players not to other isues===
We are basically using three type of issues, red for real serious issues, orange for minor issues and blue for all other like clarification. It is up to a test leader if he decide to mark an issue with red, orange or blue, but the importance should be determined from how the issue affects the game-play and to other issues. Following example will explain it a little better.

Testers have discovered several issues during task #123 testing. It is possible to combine two things to exploit game mechanism, there is one NPC dialog missing, various missing translations and no image with event instructions displayed for neutral characters.

From what you read above, it is clear we will have 4 issues for the fictional task #123:
* Combine items to exploit - this might look serious, but consider circumstances that allow to use it, consider variations with other items. But it is still an exploit and thus will be red issue.
* Missing NPC dialog - this one will be a little harder, because we must consider how much it affects the game. If the dialog just says "Thanks, bye", it is a orange minor issue and will be probably not hard to solve. On the other hand, if this specific dialog breaks a chain, makes the mission impossible or hard to complete, then it will be the red issue and the fact that an expliot above might look much more important, both have same importance from game-play point of view, because it strongly affects the game.
* Various missing translations - missing translations are usually only minor issues unless it causes other troubles (a player will not get important information for example).
* No image with event instructions for neutrals - this might be serious red issue in case it is a common problem that signalize something very wrong and the fact it is not that important as the exploit plays no role. On the other hand, when the missing NPC dialog above should tell you that this feature requires non-neutral allegiance, it is just an orange minor issue that will be probably solved when the missing dialog is fixed

===Never trust others===
Always make sure that a fix was actually delivered. Mostly everyone can mark an issue as resolved and also write you a story about happy future but it is you who (is going to) lead a test so you should make sure yourself that the subject of testing is actually present on target server and that it is possible to even start testing. It is you who must confirm that a fix is really part of the game, by own testing or by opening new testing for testers. It is you who re-test all issues reported by testers and confirm them for developers. Of course that you do not have to do everything yourself, ask other (different) testers to help. But it is your responsibility what instructions say to testers, if they are able to test and if you do not accept issues that actually are not issues.

===Never progress tasks by default===
When you go to manage tasks on the Test team board, never progress them by default. The first column where the task goes after a testing is done is back to waiting. The testing must be evaluated first and the task can progress only in case that no known issue prevent that.

To progress a task from Yubo to Gingo, there is no problem with translation issues, not everything was probably done before testing on Yubo and translators will work on strings when it is final.

On the other hand, when a task should progress from Gingo to Atys, there must be no known issues opened except those that are not too serious and can't be solved within the testing. Such issues will go to Bugs board at the end.

===Keep eye on your tasks===
Once you decided to guide a task and carry about a testing as the test leader, you should not just properly prepare the testing and review its results at the end, but you should also checking the current PAD every few days to answer questions of testers and to see progress. Mark all parts of a tester's report that you have evaluated and give them comments. All your PAD changes and updates should be documented in your own report and marked with date and time, every closed issue should be marked with date time and reason.

In case the PAD is getting too long it is a signal that the tested feature needs work of a developer, clarify details or test restart. Close the test, check the situation yourself. Discuss it with developers, translators or lorists to resolve what is possible. review changes yourself, create new PAD with only current issues and properly close all issues in the old PAD. Start new testing. Where there were any promises done by developers, make sure they really performed all changes and track progress.

Being a Test Team Coordinator

2020-12-25T15:32:25Z

Moniq: working version 3

Being a Test Team Coordinator

2020-12-25T15:03:11Z

Moniq: working version 2

Being a Test Team Coordinator

2020-12-25T14:20:37Z

Moniq: (working version)

The Test Team Handbook/5 - Test board organization

2020-12-25T13:30:39Z

Moniq: /* Board users */ column names update

{{Trad
|DE =The Test Team Handbook|DEs=5
|EN =The Test Team Handbook|ENs=0
|ES =The Test Team Handbook|ESs=5
|FR =The Test Team Handbook|FRs=5
|RU =The Test Team Handbook|RUs=5
|H =
|palette=Grey
}}
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
[[File:Test board diagram.png|thumb|alt=Test board process diagram|Test board process diagram]]
This document describes details how tasks on the Test team board are organized.

=Theory=
The board divides whole process into seven steps, with progress from left to right. Odd columns are meant for management and '''Non-Testers''' in the team. Every other column involves testing and is meant for '''Testers'''.

Every task starts in either '''Blocked for Yubo''', '''Blocked for Gingo''' or '''Blocked for Atys''' column. It determines on which server the testing is initially placed. If the task progress (pass all server testing) it moves to right to next server or to end its lifetime as completed in the '''Done''' column.

The task remains "on server" and undertake one or more Test rounds/sessions until the all known or newly discovered issues are solved. The board organization use five main settings to indicate task details to all team members no matter of the current role.
* column on the board - how is overall task progress
* task position in column - priority within the current column
* task colour - general state indication: new (yellow), ok (green), troubles (orange), WIP (grey)
* tag stickers - various additional symptoms of the task
* deadline - the latest date by which the task must be analyzed
 
 
[[File:Tteam task elements.png|center|alt=Test Team board elements description]]
 
<center>''Board task elements''</center>

=Board users=
The work in the Test team is based on team members roles. Based on your current role you have chosen, you pay attention to different parts of the board and operate on different task base. The team itself consists of different type of Ryzom team members, pure testers who look for a running test, translators who work on strings, wiki project members who document changes, marketing team members who wants news for public, event team members who prepare games or scenes and developers who maintain the code. All of them can be, basically, divided into two groups.
* Testing, members who look for opened testing and its details
* Management members who manage tasks between testing

Team members accept (use) different roles while working in the Test team. Your first step should be to tell yourself, what would you like to do with the board now. Based on that, you pay attention to different task details and different parts (columns) of the board:
*'''For Testing:'''
**Testing on Yubo (2nd)
**Testing on Gingo (4th)
**Testing on Atys (6th)
*'''For Management:'''
**Waiting for Yubo (1st)
**Waiting for Gingo (3rd)
**Waiting for Atys (5th)
**Done (7th)

After you open a desired task, based on your role you pay attention to different task details.
* For Testing, usually testers or translators performing a testing, look for latest Testing PAD. You will find there all details related to current running test.
* For Management, use task description/comments to provide task details, external links to add all related documents and sub-tasks to review and manage opened task issues.
Some more about work in the Test team by various roles is described in [[Test Team roles]] article.

=Columns (task progress)=
The theory is that a new testing task travels during its lifetime from left to right when progress and right to left when troublesome. After each testing round or session it is decided if the task is ready to progress (move right on the board) or if there is more work on it (move left on the board).

==Waiting for Yubo==
This column contains new or actually closed tasks that will continue with testing on the Yubo server. It is a place where:
* Yubo task management should be done here (yellow or orange colour)
* developers can create new tasks for the Testing team with target on Yubo server
* translators can review translation issues found during testing (low priority due early stage)
* where all tests with issues return after testing on Yubo is closed
Before such task can continue for new testing on Yubo, a new test must be prepared. That means that all issues must be solved, all patches applied and all problems discussed.

==Testing on Yubo==
This column contains all opened tests on the Yubo server. It is a place where:
* active testers from the Test team should look (green and orange colours)
* all currently opened tests on Yubo server are placed
* non-testers can optionally review running tests here to interact with testers on PAD base (orange colour)

==Waiting for Gingo==
This column contains new or actually closed tasks that will continue with testing on the Gingo server. It is a place where
* Gingo task management should be done here (yellow or orange colour)
* developers can create new tasks for the Testing team with target on Gingo server
* translators can review translation issues found during testing
* where all tests with issues return after testing on Gingo is closed
* where all successful tests on Yubo server come (yellow colour)
Before such task can continue for new testing on Gingo, a new test must be prepared. That means that all issues must be solved, all patches applied and all problems discussed.

==Testing on Gingo==
This column contains all opened tests on the Gingo or Atys BETA server. It is a place where:
* active testers from the Test team should look (green and orange colours)
* all currently opened tests on Gingo or Atys BETA servers are placed
* non-testers can optionally review running tests here to interact with testers on PAD base (orange colour)

==Waiting for Atys==
This column contains new or actually closed tasks that will continue with testing on the Atys server. It is a place where
* non-testers should do a management of tasks that belong to Atys (yellow or orange colour)
* developers can create new tasks for the Testing team with target on Atys server
* translators can review translation issues found during testing
* where all tests with issues return after testing on Atys is closed
* where all successful tests on Gingo server come
Before such task can continue for new testing on Atys, a new test must be prepared. That means that all issues must be solved, all patches applied and all problems discussed.

==Testing on Atys==
This column contains all opened tests on the Atys server. It is a place where:
* active testers from the Test team should look (green and orange colours)
* all currently opened tests on Atys server are placed
* all currently opened tests on beta Atys server are placed
* non-testers can optionally review running tests here to interact with testers on PAD base (orange colour)

==Done==
This is a column where every task come at the end of its lifetime. Once the parent task is adjusted, testing task can be closed.

=Colours (task state)=
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
[[File:Tteam task issues.png|thumb|alt=Test Team board task with known issues|Test Team board task with known issues]]
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
[[File:Tteam task wip.png|thumb|alt=Test Team board task being adjusted by a coordinator|Test Team board task being adjusted by a coordinator]]
Each task can have one of various colours. This setting represents its state:
* Green marks tasks that are running ok, mainly opened tests and tasks in Done column
** Colour for: Testing
* Orange marks troublesome tasks, running tests with confirmed issues or closed tests with any issues preventing progress
** Colour for: Testing, Management
* Yellow marks new tasks in column, needs to be processed
** Colour for: Management
* Grey is a colour for tasks someone is currently doing management on
** Colour for: Management

=Position (task priority in current column)=
Position of a task in each column tells you how important is a work on it. Higher position inside a column means higher task priority. Please ignore the task Priority settings. It belongs to team managers to set their priority. Optionally you can choose initial priority when the task arrives to new column to tell your priority guess, based on task progress, number and seriousness of issues, overall project priority...

=Tag stickers (task symptoms)=
Each task can have one or more stickers (tags) placed on. It represents main current task "symptoms".

==Colour scheme==
Tag stickers have coloured background to help you get oriented.
* Orange is for (confirmed) issues to solve
* Pink is for (confirmed) issues on Atys
* Purple is for (confirmed) translation issues
* Yellow is for questions
* Green is for running test

==Commonly used tags==
The list is dynamic so you can create any sticker you wish, however it is useful to have some standard list of those everyone should understand.
* '''⏳ patch''' (orange): this task requires a server patch before it can progress or be (re)tested
* '''Bugs reported''' (orange): represents tasks that have any unsolved confirmed issues
* '''Bugs reported on Atys''' (pink): represents tasks that have any unsolved confirmed issues
* '''Translation issue''' (purple): represents tasks that have any unsolved translation issues
* '''Test in progress''' (green): represents that a task testing is in progress
* '''Quick''' (green): represents those tasks that have undemanding testing, it should not consume more than 30 minutes of your time
* '''Clarify first''' (yellow): test details or some aspects of testing/change are not clear and needs to be clarified first before testing can continue
* '''Dev: XYZ''' (no colour): represents a developer who to ask for details or discuss issues

=Deadline (task deadline in current column)=
Applies to open tests only, otherwise ignore. The date and time represents when the test (round) will be closed on server. It is needed to have at least basic testing done completed due the date. Deadlines are important in case you need to prepare the change for upcoming patch or if some specific features will be activated for limited time (running events, bigger tests...).

{{Portal|Forge}}
[[Category:Test|Test team]]
[[Category:Tutorials|Test team]]
[[Category:Testing Team]]
[[Category:Ryzom Team]]
[[Category:Test]]
[[Category:Tutorials]]

The Test Team Handbook/5 - Test board organization

2020-12-25T13:26:20Z

Moniq: /* Columns (task progress) */ column names update

{{Trad
|DE =The Test Team Handbook|DEs=5
|EN =The Test Team Handbook|ENs=0
|ES =The Test Team Handbook|ESs=5
|FR =The Test Team Handbook|FRs=5
|RU =The Test Team Handbook|RUs=5
|H =
|palette=Grey
}}
[[File:Test board scheme.png|thumb|alt=Test board organization scheme|Test board organization scheme]]
[[File:Test board diagram.png|thumb|alt=Test board process diagram|Test board process diagram]]
This document describes details how tasks on the Test team board are organized.

=Theory=
The board divides whole process into seven steps, with progress from left to right. Odd columns are meant for management and '''Non-Testers''' in the team. Every other column involves testing and is meant for '''Testers'''.

Every task starts in either '''Blocked for Yubo''', '''Blocked for Gingo''' or '''Blocked for Atys''' column. It determines on which server the testing is initially placed. If the task progress (pass all server testing) it moves to right to next server or to end its lifetime as completed in the '''Done''' column.

The task remains "on server" and undertake one or more Test rounds/sessions until the all known or newly discovered issues are solved. The board organization use five main settings to indicate task details to all team members no matter of the current role.
* column on the board - how is overall task progress
* task position in column - priority within the current column
* task colour - general state indication: new (yellow), ok (green), troubles (orange), WIP (grey)
* tag stickers - various additional symptoms of the task
* deadline - the latest date by which the task must be analyzed
 
 
[[File:Tteam task elements.png|center|alt=Test Team board elements description]]
 
<center>''Board task elements''</center>

=Board users=
The work in the Test team is based on team members roles. Based on your current role you have chosen, you pay attention to different parts of the board and operate on different task base. The team itself consists of different type of Ryzom team members, pure testers who look for a running test, translators who work on strings, wiki project members who document changes, marketing team members who wants news for public, event team members who prepare games or scenes and developers who maintain the code. All of them can be, basically, divided into two groups.
* Testing, members who look for opened testing and its details
* Management members who manage tasks between testing

Team members accept (use) different roles while working in the Test team. Your first step should be to tell yourself, what would you like to do with the board now. Based on that, you pay attention to different task details and different parts (columns) of the board:
*'''For Testing:'''
**Testing on Yubo (2nd)
**Testing on Gingo (4th)
**Testing on Atys (6th)
*'''For Management:'''
**Blocked for Yubo (1st)
**Blocked for Gingo (3rd)
**Blocked for Atys (5th)
**Done (7th)

After you open a desired task, based on your role you pay attention to different task details.
* For Testing, usually testers or translators performing a testing, look for latest Testing PAD. You will find there all details related to current running test.
* For Management, use task description/comments to provide task details, external links to add all related documents and sub-tasks to review and manage opened task issues.
Some more about work in the Test team by various roles is described in [[Test Team roles]] article.

=Columns (task progress)=
The theory is that a new testing task travels during its lifetime from left to right when progress and right to left when troublesome. After each testing round or session it is decided if the task is ready to progress (move right on the board) or if there is more work on it (move left on the board).

==Waiting for Yubo==
This column contains new or actually closed tasks that will continue with testing on the Yubo server. It is a place where:
* Yubo task management should be done here (yellow or orange colour)
* developers can create new tasks for the Testing team with target on Yubo server
* translators can review translation issues found during testing (low priority due early stage)
* where all tests with issues return after testing on Yubo is closed
Before such task can continue for new testing on Yubo, a new test must be prepared. That means that all issues must be solved, all patches applied and all problems discussed.

==Testing on Yubo==
This column contains all opened tests on the Yubo server. It is a place where:
* active testers from the Test team should look (green and orange colours)
* all currently opened tests on Yubo server are placed
* non-testers can optionally review running tests here to interact with testers on PAD base (orange colour)

==Waiting for Gingo==
This column contains new or actually closed tasks that will continue with testing on the Gingo server. It is a place where
* Gingo task management should be done here (yellow or orange colour)
* developers can create new tasks for the Testing team with target on Gingo server
* translators can review translation issues found during testing
* where all tests with issues return after testing on Gingo is closed
* where all successful tests on Yubo server come (yellow colour)
Before such task can continue for new testing on Gingo, a new test must be prepared. That means that all issues must be solved, all patches applied and all problems discussed.

==Testing on Gingo==
This column contains all opened tests on the Gingo or Atys BETA server. It is a place where:
* active testers from the Test team should look (green and orange colours)
* all currently opened tests on Gingo or Atys BETA servers are placed
* non-testers can optionally review running tests here to interact with testers on PAD base (orange colour)

==Waiting for Atys==
This column contains new or actually closed tasks that will continue with testing on the Atys server. It is a place where
* non-testers should do a management of tasks that belong to Atys (yellow or orange colour)
* developers can create new tasks for the Testing team with target on Atys server
* translators can review translation issues found during testing
* where all tests with issues return after testing on Atys is closed
* where all successful tests on Gingo server come
Before such task can continue for new testing on Atys, a new test must be prepared. That means that all issues must be solved, all patches applied and all problems discussed.

==Testing on Atys==
This column contains all opened tests on the Atys server. It is a place where:
* active testers from the Test team should look (green and orange colours)
* all currently opened tests on Atys server are placed
* all currently opened tests on beta Atys server are placed
* non-testers can optionally review running tests here to interact with testers on PAD base (orange colour)

==Done==
This is a column where every task come at the end of its lifetime. Once the parent task is adjusted, testing task can be closed.

=Colours (task state)=
[[File:Tteam task open.png|thumb|alt=Test Team board task opened for testing|Test Team board task opened for testing]]
[[File:Tteam task issues.png|thumb|alt=Test Team board task with known issues|Test Team board task with known issues]]
[[File:Tteam task new.png|thumb|alt=Test Team board task ready to be processed|Test Team board task ready to be processed]]
[[File:Tteam task wip.png|thumb|alt=Test Team board task being adjusted by a coordinator|Test Team board task being adjusted by a coordinator]]
Each task can have one of various colours. This setting represents its state:
* Green marks tasks that are running ok, mainly opened tests and tasks in Done column
** Colour for: Testing
* Orange marks troublesome tasks, running tests with confirmed issues or closed tests with any issues preventing progress
** Colour for: Testing, Management
* Yellow marks new tasks in column, needs to be processed
** Colour for: Management
* Grey is a colour for tasks someone is currently doing management on
** Colour for: Management

=Position (task priority in current column)=
Position of a task in each column tells you how important is a work on it. Higher position inside a column means higher task priority. Please ignore the task Priority settings. It belongs to team managers to set their priority. Optionally you can choose initial priority when the task arrives to new column to tell your priority guess, based on task progress, number and seriousness of issues, overall project priority...

=Tag stickers (task symptoms)=
Each task can have one or more stickers (tags) placed on. It represents main current task "symptoms".

==Colour scheme==
Tag stickers have coloured background to help you get oriented.
* Orange is for (confirmed) issues to solve
* Pink is for (confirmed) issues on Atys
* Purple is for (confirmed) translation issues
* Yellow is for questions
* Green is for running test

==Commonly used tags==
The list is dynamic so you can create any sticker you wish, however it is useful to have some standard list of those everyone should understand.
* '''⏳ patch''' (orange): this task requires a server patch before it can progress or be (re)tested
* '''Bugs reported''' (orange): represents tasks that have any unsolved confirmed issues
* '''Bugs reported on Atys''' (pink): represents tasks that have any unsolved confirmed issues
* '''Translation issue''' (purple): represents tasks that have any unsolved translation issues
* '''Test in progress''' (green): represents that a task testing is in progress
* '''Quick''' (green): represents those tasks that have undemanding testing, it should not consume more than 30 minutes of your time
* '''Clarify first''' (yellow): test details or some aspects of testing/change are not clear and needs to be clarified first before testing can continue
* '''Dev: XYZ''' (no colour): represents a developer who to ask for details or discuss issues

=Deadline (task deadline in current column)=
Applies to open tests only, otherwise ignore. The date and time represents when the test (round) will be closed on server. It is needed to have at least basic testing done completed due the date. Deadlines are important in case you need to prepare the change for upcoming patch or if some specific features will be activated for limited time (running events, bigger tests...).

{{Portal|Forge}}
[[Category:Test|Test team]]
[[Category:Tutorials|Test team]]
[[Category:Testing Team]]
[[Category:Ryzom Team]]
[[Category:Test]]
[[Category:Tutorials]]

Recharge crystal

2020-11-27T13:47:14Z

Moniq: /* Known catalyzer qualities */ cpy&paste issue fixed

[[File:Cristal ammo.png|cadre|left|Recharge Crystal Icon]]
This is a type of special consumables (also called Sap crystals, Sap Recharge or just crystals) that help you to charge [[Sap]] into your weapon. This sap can be used later to cast enchanted spell. It is a faster alternative to Sap Recharge spell but can do the work instantly. Unless using of Sap Recharge spell, when you turn [[Dapper]]s into a Sap that is charged, Recharge crystals are already prepared to use and charging your weapons will not cost any Dappers..

==Recharge crystal quality and type==
[[File:Merchant federal sap cats.png|thumb|alt=Federal merchant offering various Recharge crystal qualities for sale|Federal merchant offering various Recharge crystal qualities for sale]]
It is a general rule that a crystal quality tells you how many Sap points will be charged into a weapon when it is used. By the matter of Atys currency it also tells you how many Dappers would be needed to create such crystal (without work). There exist several types ''((OOC: item sheets))'' of Recharge crystals with different names but working the same and the following "energy" equality always applies: 1 sap point is equal to 1 dapper which is equal to crystal of quality 1.

===Known crystal qualities===
* Quality 100
* Quality 200
* Quality 250
* Quality 500

'''Note:''' Free to play and unsubscribed characters are not limited by quality 150 and can use all available crystals.

==How to get Recharge crystals==
There exists several ways how to get Recharge crystals:
* By trade with various merchants:
** For [[Nation points]]
** For [[Player_versus_Player#PvP_points|PvP points]]
** For [[Elyps]]
* As reward for playing tokens on the [[Wheel of fortune]]
* As reward from various [[OOC]] events
* By exchange with another character, experience catalyzers are tradeable

==Using Recharge crystals==
[[File:Using recharge crystal.png|thumb|alt=Using Recharge crystal|Using Recharge crystal]]
Have some Recharge crystals in your Bag. Put a weapon with any enchanted spell in your right hand and right-click the stack of Recharge crystals and select '''Recharge Right Hand''' option. One crystal will be consumed and turned into Sap charged in the weapon.

'''Note:''' You can charge only weapons that have Sap Load higher than 0. It determines how many sap points is possible to load into such weapon.

Recharge crystal

2020-11-27T13:32:46Z

Moniq: created

[[File:Cristal ammo.png|cadre|left|Recharge Crystal Icon]]
This is a type of special consumables (also called Sap crystals, Sap Recharge or just crystals) that help you to charge [[Sap]] into your weapon. This sap can be used later to cast enchanted spell. It is a faster alternative to Sap Recharge spell but can do the work instantly. Unless using of Sap Recharge spell, when you turn [[Dapper]]s into a Sap that is charged, Recharge crystals are already prepared to use and charging your weapons will not cost any Dappers..

==Recharge crystal quality and type==
[[File:Merchant federal sap cats.png|thumb|alt=Federal merchant offering various Recharge crystal qualities for sale|Federal merchant offering various Recharge crystal qualities for sale]]
It is a general rule that a crystal quality tells you how many Sap points will be charged into a weapon when it is used. By the matter of Atys currency it also tells you how many Dappers would be needed to create such crystal (without work). There exist several types ''((OOC: item sheets))'' of Recharge crystals with different names but working the same and the following "energy" equality always applies: 1 sap point is equal to 1 dapper which is equal to crystal of quality 1.

===Known catalyzer qualities===
* Quality 100
* Quality 200
* Quality 250
* Quality 500

'''Note:''' Free to play and unsubscribed characters are not limited by quality 150 and can use all available crystals.

==How to get Recharge crystals==
There exists several ways how to get Recharge crystals:
* By trade with various merchants:
** For [[Nation points]]
** For [[Player_versus_Player#PvP_points|PvP points]]
** For [[Elyps]]
* As reward for playing tokens on the [[Wheel of fortune]]
* As reward from various [[OOC]] events
* By exchange with another character, experience catalyzers are tradeable

==Using Recharge crystals==
[[File:Using recharge crystal.png|thumb|alt=Using Recharge crystal|Using Recharge crystal]]
Have some Recharge crystals in your Bag. Put a weapon with any enchanted spell in your right hand and right-click the stack of Recharge crystals and select '''Recharge Right Hand''' option. One crystal will be consumed and turned into Sap charged in the weapon.

'''Note:''' You can charge only weapons that have Sap Load higher than 0. It determines how many sap points is possible to load into such weapon.

Dapper

2020-11-27T11:58:42Z

Moniq: /* Uses */ corrected along testing, image removed

{{Trad
|DE=Dapper
|EN=Dapper
|ES=
|FR=Dapper
|RU=}}
[[File:Dapper.png|cadre|left|Dapper Icon]]
'''Dapper''' (plural: ''dappers'') is the universal currency of [[Atys]].

==History==
In earlier times, all the races had a bartering system for trading goods, the [[Tryker]]s of the Old Lands were the first to notice that this system could be unfair through intimidation. They soon developed a monetary system based on dappers. Dappers quickly spread to the other lands and became a universal currency and is still widely used in the New Lands.

Dappers were originally made from pearls bound in a sap-based substance. The presence of counterfeit dappers soon began to flood the markets though and the homin high authorities decided to make use of magic during the minting process, which made it much harder to counterfeit dappers.<ref>Encylopedia:Trykers and lake materials</ref>

==Uses==
Dappers are used for a wide variety of things, such as buying armour, weapons, food, [[mektoub]]s, [[teleporter pact]]s, etc. Many players also sell their crafts for dappers, though the more traditional bartering system is often used during these trades. While Dappers consist of [[Sap]], they are also used to recharge a weapons with Sap. Every use of Sap Recharge spell costs you also some money, one dapper for each point of Sap.

==References==
<references/>
{{Portal|Gameplay}}
[[Category:Glossary]]

Dapper

2020-11-27T11:40:05Z

Moniq: +recharge +icons

{{Trad
|DE=Dapper
|EN=Dapper
|ES=
|FR=Dapper
|RU=}}
[[File:Dapper.png|cadre|left|Dapper Icon]]
'''Dapper''' (plural: ''dappers'') is the universal currency of [[Atys]].

==History==
In earlier times, all the races had a bartering system for trading goods, the [[Tryker]]s of the Old Lands were the first to notice that this system could be unfair through intimidation. They soon developed a monetary system based on dappers. Dappers quickly spread to the other lands and became a universal currency and is still widely used in the New Lands.

Dappers were originally made from pearls bound in a sap-based substance. The presence of counterfeit dappers soon began to flood the markets though and the homin high authorities decided to make use of magic during the minting process, which made it much harder to counterfeit dappers.<ref>Encylopedia:Trykers and lake materials</ref>

==Uses==
[[File:Cristal_ammo.png|cadre|left|Recharge crystal Icon]]
Dappers are used for a wide variety of things, such as buying armour, weapons, food, [[mektoub]]s, [[teleporter pact]]s, etc. Many players also sell their crafts for dappers, though the more traditional bartering system is often used during these trades. While Dappers consist of [[Sap]], they are also used to release energy stored in [[Recharge crystal]]s to charge a weapons with Sap. Every use of a recharge crystal costs you few Dappers.

==References==
<references/>
{{Portal|Gameplay}}
[[Category:Glossary]]

Merchant

2020-11-27T11:39:27Z

Moniq: /* More on merchants or traders */ +link to `Recharge crystal`

{{Template:User Manual v4}}{{Trad|EN=Merchant|FR=Marchand}} {{WIP}}
[[File:Fame.jpg|200px|thumb|right|Fame]]
There are Armour, Raw Materials, Weapons, Jewellery, Hawkers, Consumables, Stable boys and several other types of merchants throughout Atys.
All of them will buy your goods.
However, what is sold in one country is not available to purchase in another.
For example, a sword put up for sale in Pyr ([[Desert]]) is not available for players to purchase in Yrkranis ([[Forest]]).
While traveling, you may wish to purchase new armour or replace a pick. If your fame is not good with a particular merchant's race, then expect to pay more and get less.

Check fame at Task-bar>Communications>FAME>YOU ('''Shift+F''').

== More on merchants or traders ==
(OCC: all of those are [[:Category:Non Playable Characters|NPC]])
* Most of them are in towns (as trainers, you buy with xp won, see P, on left colon, middle).
'''Not on [[Silan]] (only on Main Land, [[Atys]]):'''
* [[Hawker]]s are less specialized, they are moving out of the cities (several places, regarding the [[Time|seasons]], they can be in [[:Category:Tribes|tribe]] camps too...).
* In each capital, there's special merchants:
**to use your '''factions points''' (P then Advanced) to get a national pick, [[Experience Catalyzer]]s, generic mats... The name change (Imperial, Federal, Dynastic...) regarding countries.
** homins from the [[Guild:Brotherhood of the Fortunate Gubani]] sell tokens for the [[Wheel of fortune]]
<gallery>
V3 Cristal Ammo.png|To [[Recharge crystal|recharge sap]] on weapon
ICO Cataliseur XP.png|[[Experience Catalyzer|Catalyzers]]: Free accounts need them to double xp (sub have double xp and don't need them anymore)
V3 c5.png|generic mats
FH Federal Merchant 2020-05-30.png|Mac'Laury Lixie, Feredal merchant in FairHaven
Marchand royal Yrk 2019-10-11 16-04-11.png|Vani Peli, Royal merchant in Yrkanis
FH NPC Brother Fortunate 2020-05-30.png|Ba'Duffy Baxan, in Fairhaven, from de [[Guild:Brotherhood of the Fortunate Gubani]]
</gallery>
* Stable boys sell Mektoubs and hay, they are in towns. More on [[Mektoub FAQ]].

=== Links ===
Merchants and buy related:
* see [[Market]] - (about Black Market and other markets organized by [[:Category:Homins|players]], and not by NPC).
* More about [[Dapper]] (OOC: the money on Atys).
* [[Elyps]], role-play currency
* [[Nation points]] and faction points
* [[Player_versus_Player#PvP_points|PvP points]]

Other
* To the [[User_Manual#Transporters]] (or NH, for New Horizons) and [[Occupations]].
*Note: When you are in a coma, you pay for the care provided by either the [[Portal:Kami|Kami]] or the [[Portal:Karavan|Karavan]] with xp, often by passing by buys TPs in Dappers. They are NPCs but not merchants (have a look on [[Portal:Lore|Lore]] portal).
* '''[[Guild:Brotherhood of the Fortunate Gubani]]''': If interested in gambling, an avatar may purchase '''[[token]]s''' from the Gubani representative for use in the nearby [[Wheel of fortune]]. If played long enough, the avatar will gain interesting [[Titles|titles]] and more.

{{Portal|Society}}
[[Category:Non Playable Characters]] [[Category:Society]]

{{Portal bottom}}

The Test Team Handbook/2 - External team tools

2020-10-29T21:44:35Z

Moniq: /* KanBoard (KB) */ added missing links to other documents

{{Trad
|DE =The Test Team Handbook|DEs=5
|EN =The Test Team Handbook|ENs=0
|ES =The Test Team Handbook|ESs=5
|FR =The Test Team Handbook|FRs=5
|RU =The Test Team Handbook|RUs=5
|H =
|palette=Grey
}}
This document shortly describes external tools that are useful for every team member. These tools are not working in-game or just in a very limited way and you need to use external browser. The goal is not to supply any user manual just give you a basic overview about what do we use, how it could be useful and how to log in. The second part of this document is focused on members of the Test team.

=General information=
Here is a basic description of all important external tools that you should keep in mind and use.
==Ryzom chat (RC)==
You probably know the Ryzom chat already. It is a tool that allows you to read in-game chats without a need to be actually in game. You will have "~" (tilde) prefix in front of your name in case of every message sent from RC to the game. Some additional details about Ryzom chat are described in the [[Chat/RC_FAQ|RC FAQ article]].

Another important role of the Ryzom chat is also that each team or project have own private chat room available. Team chat rooms have a "t-" prefix and project chat rooms have "pj-" prefix. By default every team member supposed be member of all following rooms:
* [https://chat.ryzom.com/group/announcements #announcement]
* [https://chat.ryzom.com/group/chat-general #chat-general]
* [https://chat.ryzom.com/group/chat-ark_dev #chat-ark_dev]
Internal chat rooms are not public thus you must become a member of a team/project first to see other private rooms then default ones. In all cases if you think you have lost or didn't get access to a specific channel you should be presented on (including default ones) please contact Tamarea or Tykus.
* '''URL:''' [https://chat.ryzom.com https://chat.ryzom.com]
* '''Login:''' your character name
* '''Password:''' your account password
* '''Permissions by:''' [[User:Tamarea|Tamarea]] or [[User:Tykus|Tykus]]

==KanBoard (KB)==
KanBoard is a collaboration tool, a place where all team tasks supposed to be registered. There exists a lot of boards for various teams, projects and use. The general rule about tasks is that they travel from columns on left to columns on right as they progress. In case you miss access to any board you supposed to see please contact Tamarea.
* '''URL:''' [https://board.ryzom.com https://board.ryzom.com]
* '''Login:''' your account name
* '''Password:''' your account password
* '''Permissions by:''' [[User:Tamarea|Tamarea]]

==Ryzom cloud (Cloud)==
Ryzom cloud is a powerful tool for (not just) collaboration on documents. There are various folders and the visibility depends on your team or project membership as usually. You can work with various file types on the cloud, however for a team cooperation we use mostly Pads, a special type of document that highlights different contributors. In case you miss access to any part of the cloud please contact Tamarea. Some additional details about file formats used on the Ryzom cloud are described in [[File formats]] article <ref> You can read [[Tips for wiki contributors#With Ryzom cloud]] too. '''Caution''': the Document folder is for your personal files - no team can access it.</ref>.

There is a "[https://cloud.ryzom.com/f/1354 Ryzom-Team]" folder on the cloud that you should be able to access. You can find some useful documents for internal needs, sorted to several sub-folders.
* '''URL:''' [https://cloud.ryzom.com https://cloud.ryzom.com]
* '''Login:''' your account name
* '''Password:''' your account password
* '''Permissions by:''' [[User:Tamarea|Tamarea]]

==Ryzom Wiki==
Ryzom wiki is the main place for all documentation. It is not a tool you will probably need to use directly in your team, however it contains a lot of useful information about the game and its world. The Wiki is maintained by the Ryzom Wiki project. Viewing documents does not require any authentication, however you must have an account in case you wish to contribute. As a member of a Ryzom team consider your registration and updating your profile page <ref>More on [[:Category:Help]].</ref>.
* '''URL:''' [https://wiki.ryzom.com https://wiki.ryzom.com]
* '''Login:''' your character name
* '''Password:''' specific for the wiki
* '''Permissions by:''' [[User:Zorroargh|Zorroargh]]

More about wiki account creation on [[Help:Why create an account?]].

==Server status==
This small application is used to quick check the state of all three servers. There is no need to authenticate yourself and it is a passive too that displays what is running and what is not. Please remember that this tool is unable to cover wrong functionality of a component, it just tells you if it is running or not. In best case all icons on this page are green (thus everything is running).
* '''URL:''' [https://app.ryzom.com/app_server_status/ https://app.ryzom.com/app_server_status/]
* '''Login:''' not needed
* '''Password:''' not needed
* '''Permissions by:''' not needed

=As a member of the Test Team=
Here are some additional details for members of the Test team. In case you are lost or need a help, contact one of [[Test_Team#Coordinators|Test team coordinators]] on the team chat (see below).
==Ryzom chat (RC)==
You supposed to see [https://chat.ryzom.com/group/t-test #t-test] room by default and all discussion about testing supposed to go there, unless you need to interact with members from other teams. Feel free to ask about everything that is not clear, about your work in team, tools, a test details or your questions and issues that appeared during your testing. Feel free to suggest anything that will help run the team or fix any issue you have discovered.

==KanBoard (KB)==
You supposed to see "[https://board.ryzom.com/?controller=BoardViewController&action=show&project_id=51 [Team] Test]" board where all current or near-future tests have a place. The board is separated to various columns and tasks travel from left to right. However the most important for you are three of those columns:
* '''Testing on Yubo''', where a list of tasks to be tested on Yubo server is
* '''Testing on Gingo''', with a list of tasks that supposed to undertake final testing on Gingo server
* '''Testing on Atys''', where you can find tasks that need to be tested after it was released on Atys
You can comment each task as you wish, however remember please that each specific testing has a Testing PAD with instructions and all your testing reports should go there not to comments on the board. The link to a corresponding pad is usually attached to the task. More details about Test board organization is covered by [[The_Test_Team_Handbook/5_-_Test_board_organization|Test board organization]] chapter, more details about work for testers is described in [[Test_Team_roles#Testers|Test Team roles]]

==Ryzom cloud (Cloud)==
As a member of the Testing team you supposed to see the "[https://cloud.ryzom.com/f/1355 Test-Team]" folder. It contains various sub-folders however for the testing itself you need mostly "[https://cloud.ryzom.com/f/31392 1 - DEV_Yubo]", "[https://cloud.ryzom.com/f/31396 2 - TEST_Gingo]" and "[https://cloud.ryzom.com/f/34247 3 - LIVE_Atys]". All three folders are similar, one for each testing server and one for the Live server. All contain several other sub-folders:
* '''1 - Ongoing''' contains pads related to current opened testing
* '''2 - Minor issues''' contains pads from previous testing that contain issues to be discussed and solved
* '''3 - OK''' is a folder for recently finished testing
* '''4 - Archive''' is a place where all documents form testing will end after some time
Every existing testing task usually has a testing PAD that contains instructions about the test itself and is separated into several parts. Actual form of a Testing PAD is up to each Test Guide (a Coordinator who cares about the test), however there exists a [https://cloud.ryzom.com/f/34169 template], [https://cloud.ryzom.com/f/36218 self-describing example] and a [https://cloud.ryzom.com/f/36039 PAD with help] you can check.
Another important sub-folders are:
* [https://cloud.ryzom.com/f/32249 TT-Library] where you can find some useful documents related to the Test Team
* [https://cloud.ryzom.com/f/151402 Test related files] where you can store screenshots from your testing to link in a Testing PAD

{{Portal|Forge}}
[[Category:Test|Test team]]
[[Category:Testing Team]]
[[Category:Ryzom Team]]
[[Category:Test]]
[[Category:Tutorials]]

Guild:Phaedreas Tears

2020-10-28T12:48:51Z

Moniq: /* 15 years and first true neutral */ bittty's image description

{{Tabs
|bord=2px solid #{{ColorAtys|type=dark|group=ranger}}
|bg_frame=#{{ColorAtys|type=bg|group=ranger}}
|round=5em
|align_tab=center

|Tab-1={{3DText|text='''The Tears'''}}
|URL-1=Guild:Phaedreas Tears
|bg_Tab-1=#{{ColorAtys|type=light|group=ranger}}
|Pic-1=Phaedreas Tears.png

|Tab-2={{3DText|text='''OOC information'''}}
|URL-2=Guild:Phaedreas Tears/OOC
|bg_Tab-2=#{{ColorAtys|type=light|group=OOC}}
|Pic-2=Dummy.png
}}{{Guild
|name=Phaedrea's Tears
|Icon=Phaedreas Tears.png
|Leader= [[User:Itzy|Itzy]]
|Hall=[[Yrkanis (city)|Yrkanis]]
|Nation=none
|Faction=Neutral
|}}<noinclude>{{Trad
|DE=Gilde:Phaedreas Tears|DEs=5
|EN=Guild:Phaedreas Tears|ENs=0
|ES=Gremio:Phaedreas Tears|ESs=5
|FR=Guilde:Phaedreas Tears|FRs=1
|RU=Гильда:Phaedreas Tears|RUs=5
|palette=ranger
}}</noinclude>__TOC__

The Guild of Phaedreas Tears holds its center in [[Yrkanis]] near the Karavan Altar. It is open to all Homins of good well who are willing to abjure violence against other Homins and to aid those in need regardless of their beliefs. The Guild claims own allegiance to be neutral to factions and nations, its members have no religion. Some of the Guild members seek to become Rangers, but that is not required.

The Guild of Phaedreas Tears is currently lead by Guild leader [[User:Itzy|Itzy]]. Guild members are disallowed to fight with other homins however we know 2 OP incidents where the Guild was involved. The Guild is officially using English in communication with others. By the Guild register records the Guild controls 3 other Guilds, ''Itzy's Minions'', ''Shed Tears'' and ''Slight Risk''.

{{Quotation|''Mac'Od Bittty, former Guild Leader''|
Phaedrea's Tears is well alive and looking for a few good members. We are Nation and Faction Neutral, help all who have need, and do not fight other homins. We honor '''[[Tyneetryk]]''', of blessed memory, in that attitude. We expect members to work towards maximum Fame for all Nations and Factions. Working to become a Ranger Aspirant is desirable but not required. Being helpful to other homins, regardless of their affiliation, is expected, and use of guild resources to that end is encouraged. If this sounds good to you, contact any member of Phaedrea's Tears and we can discuss it.}}

==General Information==
''We offer assistance to any who ask it, but we assist, we do not lift up those who will not work to lift themselves. If you would join us be prepared to work hard to advance yourself.''
[[File:Pt lucio 1.png|right|thumb|450px|Guild event on 16th Aniversary of PT at Tyneetryk's memorial place, Virginia Falls]]
{{GuildGeneralInfo
|image=
|server=Atys
|land=[[Verdant Heights]]
|GH=[[Yrkanis (city)|Yrkanis]]
|FactionAlignment=Neutral
|RacialAlignment=Neutral
|AllowedRaces=All
|pvpStance=None
|rpStance=Semi
|website=
|}}
====Officials====
* '''✩ Leader:''' [[user:Itzy|Itzy]]
* '''✩ High Officers:''' Atanae, [[user:Bitttymacod|Mac'Od Bittty]], Ferishan, Fleetwood, Gabbystar, Hwinoree, Microgiant, [[User:Moniq|Moniq]], Rizyinshi and Sunray
* '''✩ Officers:''' Copesious, Estellar, Joelley, Joneyentee, Josemg, Milada, Rivatha, Sarlic and Vlamma

== History ==
Phaedreas Tears was founded in October, 2004. It was initially aligned as a Matis, Karavan, Guild for the purpose of guildhall space and teleports. However, it has always been willing to aid '''all''' Homins in need.

{{Quotation|''From the tale of Sumguy''|
Phaedrea arrived to look upon her young friends, noticed them leaving, and although joyful, wept, for such was the warmth of her heart for all Matis kind. And so in honour of this lady, the band of Matis bound in friendship and love for Phaedrea created the Guild that would be known henceforth as Phaedrea’s Tears … Each Tear being a Matis soul, to defend Yrkanis against evil, in all its forms.

Such is the essence of Tears. If you love King Yrkanis and the Lady Phaedrea, if you hold friendship dear above all else, then you already are a Tear at true heart. You know Life Is Beautiful, because you share it unasked. When the clouds grow dark and the rain sets in, your face turns high, to the sky. When they skitter and run before a strong wind, you'll grab a javing, by its feet, try to fly. Every snowfall makes a snowball, when you're cold you make a huddle. When you hear a plaintive cry you will, every time, reply. Before you know it, you've made another friend.

Such is the light of Jena which glows in every young homin, never let it blow out.

We came to the lush Verdant Heights to regrow the beautiful civilization destroyed by the kitin onslaught, and there is much to be relearnt. A Tear is expected to find their own place in this endeavour and help others to find theirs. Nothing is learned so well as that which a homin discovers for themselves, many new discoveries have been made when a fresh pair of eyes has looked over old ground.

A Tear must uphold the good name of the guild and help, if they can, whenever asked. Once a Tear has paid their respects to the Green Seeds, and as soon as they are able, they should be proud to perform their civic duty keeping the pathways of Majestic Gardens free from ragus and gingos. Weapons, amplifying gloves and picks should not be wielded in the guildhall, and footwear must be removed before entering; crafting tools may be used with caution, well away from the polished furnishings.
}}

===Tyneetryk's times===
The official alignment of Phaedrea's Tears was changed following the server crash that divided the ownership by GameForge and Winchgate. Shortly before upcoming split (2010) was the guild lead by Joneyentee and the guild claimed itself to be officially neutral while the Karavan allegiance was used only because of teleportation pacts. The neutral and anti-PvP stance of he Guild were set by Tyneetryk (around February 6th 2012<ref>[[User:Tyneetryk|Tyneetryk]]: [[Special:Contributions/Tyneetryk|contributions]]</ref>) , and after her departure for the Summerlands, kept by Ferishan and [[User:Bitttymacod|Mac'Od Bittty]].

{{Quotation|''Tyneetryk, former Guild Leader''|
Long ago the warriors of Phaedrea rose to fight the oppression of the Kitins. Much has changed since then and now the guild is primarily focused in aiding the newly arrived refugees on Silan and the Mainland to find a place for themselves on Atys.

Phaedrea's Tears is open to players with various interests. It boasts a friendly and supportive environment. Tears is the only actively recruiting guild which is completely neutral and all of the current active members are also completely neutral. The guild does not take sides in the Karavan-Kami conflict, however individual members are allowed to participate in PvP as they wish.

The guild does not actively invite or cajole players into joining, but we give unconditional help and assistance to whoever needs it and let them choose to join if they wish.

We are also active on Silan but we have a policy of refusing guild requests until a player has established a character on the mainland. We believe that players should have a chance to see the various guilds, discover what each one has to offer and so make an informed decision.

As already stated, the guild's main goal is to help new players on Atys, both on Silan and the Mainland. Roleplay is welcome but not mandatory.
}}
====Officials====
* '''✩ Leader:''' [[Tyneetryk]]
* '''✩ High Officers:''' Byrana, Ferishan, Joneyentee, Shadia,
* '''✩ Officers:''' Bryanna, Fyranna, Joelley, [[Teeneemai|Minimei]], Shadiaz

===15 years and first true neutral===
[[File:Screenshot 2017-04-23 002 Giselher.jpg|400px|thumb|Virginia falls. In memoriam [[Tyneetryk]]...]]
[[File:Mc'Od Bittty.jpg|64px|thumb|left|Mc'Od Bittty]]
Times after Tyneetryk were years of holding the new spirit of the Guild. [[Teeneemai]] has established [[Guild:Tyneetryk's Tears|Tyneetryk's Tears]] to hold the beloved leader name and the Guild itself focus more on members quality than quantity. The leadership of [[user:Bitttymacod|Mac'Od Bittty]] has built small but solid members base that hold the legacy of Tyneetryk. ''15 years old and first <ref>''This statement is contested, but we are certainly the longest lasting.'' --Mac'Od Bittty</ref> of true neutral guilds in Atys.''

{{Quotation|''Mac'Od Bittty, former Guild Leader''|
...Much has changed since then. Now the guild is primarily focused in aiding the newly arrived refugees on Silan and the Mainland to find a place for themselves on Atys. Phaedrea's Tears is open to all homins who pledge to shun violence against other homins and keep a neutral attitude towards all Nations and both Powers. The guildhall is in Yrkanis for reasons related to our history.
}}
====Officials====
* '''✩ Leader:''' [[user:Bitttymacod|Mac'Od Bittty]]
* '''✩ High Officers:''' Ferishan, Fleetwood, Hwinoree, [[user:Itzy|Itzy]], Joneyentee, [[User:Moniq|Moniq]], Rivatha, Saija
* '''✩ Officers:''' Bitesized, Estellar, Joelley, Milada, Rizyinshi, Sarlic, Vlamma

<noinclude>{{clear}}{{last version link|Guild:Phaedreas Tears}}
----
<references/>
----

[[Category:Guilds|{{PAGENAME}}]]</noinclude>

Guild:Phaedreas Tears

2020-10-28T12:43:37Z

Moniq: /* Tyneetryk's times */ bittty's profile link fixed

{{Tabs
|bord=2px solid #{{ColorAtys|type=dark|group=ranger}}
|bg_frame=#{{ColorAtys|type=bg|group=ranger}}
|round=5em
|align_tab=center

|Tab-1={{3DText|text='''The Tears'''}}
|URL-1=Guild:Phaedreas Tears
|bg_Tab-1=#{{ColorAtys|type=light|group=ranger}}
|Pic-1=Phaedreas Tears.png

|Tab-2={{3DText|text='''OOC information'''}}
|URL-2=Guild:Phaedreas Tears/OOC
|bg_Tab-2=#{{ColorAtys|type=light|group=OOC}}
|Pic-2=Dummy.png
}}{{Guild
|name=Phaedrea's Tears
|Icon=Phaedreas Tears.png
|Leader= [[User:Itzy|Itzy]]
|Hall=[[Yrkanis (city)|Yrkanis]]
|Nation=none
|Faction=Neutral
|}}<noinclude>{{Trad
|DE=Gilde:Phaedreas Tears|DEs=5
|EN=Guild:Phaedreas Tears|ENs=0
|ES=Gremio:Phaedreas Tears|ESs=5
|FR=Guilde:Phaedreas Tears|FRs=1
|RU=Гильда:Phaedreas Tears|RUs=5
|palette=ranger
}}</noinclude>__TOC__

The Guild of Phaedreas Tears holds its center in [[Yrkanis]] near the Karavan Altar. It is open to all Homins of good well who are willing to abjure violence against other Homins and to aid those in need regardless of their beliefs. The Guild claims own allegiance to be neutral to factions and nations, its members have no religion. Some of the Guild members seek to become Rangers, but that is not required.

The Guild of Phaedreas Tears is currently lead by Guild leader [[User:Itzy|Itzy]]. Guild members are disallowed to fight with other homins however we know 2 OP incidents where the Guild was involved. The Guild is officially using English in communication with others. By the Guild register records the Guild controls 3 other Guilds, ''Itzy's Minions'', ''Shed Tears'' and ''Slight Risk''.

{{Quotation|''Mac'Od Bittty, former Guild Leader''|
Phaedrea's Tears is well alive and looking for a few good members. We are Nation and Faction Neutral, help all who have need, and do not fight other homins. We honor '''[[Tyneetryk]]''', of blessed memory, in that attitude. We expect members to work towards maximum Fame for all Nations and Factions. Working to become a Ranger Aspirant is desirable but not required. Being helpful to other homins, regardless of their affiliation, is expected, and use of guild resources to that end is encouraged. If this sounds good to you, contact any member of Phaedrea's Tears and we can discuss it.}}

==General Information==
''We offer assistance to any who ask it, but we assist, we do not lift up those who will not work to lift themselves. If you would join us be prepared to work hard to advance yourself.''
[[File:Pt lucio 1.png|right|thumb|450px|Guild event on 16th Aniversary of PT at Tyneetryk's memorial place, Virginia Falls]]
{{GuildGeneralInfo
|image=
|server=Atys
|land=[[Verdant Heights]]
|GH=[[Yrkanis (city)|Yrkanis]]
|FactionAlignment=Neutral
|RacialAlignment=Neutral
|AllowedRaces=All
|pvpStance=None
|rpStance=Semi
|website=
|}}
====Officials====
* '''✩ Leader:''' [[user:Itzy|Itzy]]
* '''✩ High Officers:''' Atanae, [[user:Bitttymacod|Mac'Od Bittty]], Ferishan, Fleetwood, Gabbystar, Hwinoree, Microgiant, [[User:Moniq|Moniq]], Rizyinshi and Sunray
* '''✩ Officers:''' Copesious, Estellar, Joelley, Joneyentee, Josemg, Milada, Rivatha, Sarlic and Vlamma

== History ==
Phaedreas Tears was founded in October, 2004. It was initially aligned as a Matis, Karavan, Guild for the purpose of guildhall space and teleports. However, it has always been willing to aid '''all''' Homins in need.

{{Quotation|''From the tale of Sumguy''|
Phaedrea arrived to look upon her young friends, noticed them leaving, and although joyful, wept, for such was the warmth of her heart for all Matis kind. And so in honour of this lady, the band of Matis bound in friendship and love for Phaedrea created the Guild that would be known henceforth as Phaedrea’s Tears … Each Tear being a Matis soul, to defend Yrkanis against evil, in all its forms.

Such is the essence of Tears. If you love King Yrkanis and the Lady Phaedrea, if you hold friendship dear above all else, then you already are a Tear at true heart. You know Life Is Beautiful, because you share it unasked. When the clouds grow dark and the rain sets in, your face turns high, to the sky. When they skitter and run before a strong wind, you'll grab a javing, by its feet, try to fly. Every snowfall makes a snowball, when you're cold you make a huddle. When you hear a plaintive cry you will, every time, reply. Before you know it, you've made another friend.

Such is the light of Jena which glows in every young homin, never let it blow out.

We came to the lush Verdant Heights to regrow the beautiful civilization destroyed by the kitin onslaught, and there is much to be relearnt. A Tear is expected to find their own place in this endeavour and help others to find theirs. Nothing is learned so well as that which a homin discovers for themselves, many new discoveries have been made when a fresh pair of eyes has looked over old ground.

A Tear must uphold the good name of the guild and help, if they can, whenever asked. Once a Tear has paid their respects to the Green Seeds, and as soon as they are able, they should be proud to perform their civic duty keeping the pathways of Majestic Gardens free from ragus and gingos. Weapons, amplifying gloves and picks should not be wielded in the guildhall, and footwear must be removed before entering; crafting tools may be used with caution, well away from the polished furnishings.
}}

===Tyneetryk's times===
The official alignment of Phaedrea's Tears was changed following the server crash that divided the ownership by GameForge and Winchgate. Shortly before upcoming split (2010) was the guild lead by Joneyentee and the guild claimed itself to be officially neutral while the Karavan allegiance was used only because of teleportation pacts. The neutral and anti-PvP stance of he Guild were set by Tyneetryk (around February 6th 2012<ref>[[User:Tyneetryk|Tyneetryk]]: [[Special:Contributions/Tyneetryk|contributions]]</ref>) , and after her departure for the Summerlands, kept by Ferishan and [[User:Bitttymacod|Mac'Od Bittty]].

{{Quotation|''Tyneetryk, former Guild Leader''|
Long ago the warriors of Phaedrea rose to fight the oppression of the Kitins. Much has changed since then and now the guild is primarily focused in aiding the newly arrived refugees on Silan and the Mainland to find a place for themselves on Atys.

Phaedrea's Tears is open to players with various interests. It boasts a friendly and supportive environment. Tears is the only actively recruiting guild which is completely neutral and all of the current active members are also completely neutral. The guild does not take sides in the Karavan-Kami conflict, however individual members are allowed to participate in PvP as they wish.

The guild does not actively invite or cajole players into joining, but we give unconditional help and assistance to whoever needs it and let them choose to join if they wish.

We are also active on Silan but we have a policy of refusing guild requests until a player has established a character on the mainland. We believe that players should have a chance to see the various guilds, discover what each one has to offer and so make an informed decision.

As already stated, the guild's main goal is to help new players on Atys, both on Silan and the Mainland. Roleplay is welcome but not mandatory.
}}
====Officials====
* '''✩ Leader:''' [[Tyneetryk]]
* '''✩ High Officers:''' Byrana, Ferishan, Joneyentee, Shadia,
* '''✩ Officers:''' Bryanna, Fyranna, Joelley, [[Teeneemai|Minimei]], Shadiaz

===15 years and first true neutral===
[[File:Screenshot 2017-04-23 002 Giselher.jpg|400px|thumb|Virginia falls. In memoriam [[Tyneetryk]]...]]
[[File:Mc'Od Bittty.jpg|64px|Thumb|left|Mc'Od Bittty]]
Times after Tyneetryk were years of holding the new spirit of the Guild. [[Teeneemai]] has established [[Guild:Tyneetryk's Tears|Tyneetryk's Tears]] to hold the beloved leader name and the Guild itself focus more on members quality than quantity. The leadership of [[user:Bitttymacod|Mac'Od Bittty]] has built small but solid members base that hold the legacy of Tyneetryk. ''15 years old and first <ref>''This statement is contested, but we are certainly the longest lasting.'' --Mac'Od Bittty</ref> of true neutral guilds in Atys.''

{{Quotation|''Mac'Od Bittty, former Guild Leader''|
...Much has changed since then. Now the guild is primarily focused in aiding the newly arrived refugees on Silan and the Mainland to find a place for themselves on Atys. Phaedrea's Tears is open to all homins who pledge to shun violence against other homins and keep a neutral attitude towards all Nations and both Powers. The guildhall is in Yrkanis for reasons related to our history.
}}
====Officials====
* '''✩ Leader:''' [[user:Bitttymacod|Mac'Od Bittty]]
* '''✩ High Officers:''' Ferishan, Fleetwood, Hwinoree, [[user:Itzy|Itzy]], Joneyentee, [[User:Moniq|Moniq]], Rivatha, Saija
* '''✩ Officers:''' Bitesized, Estellar, Joelley, Milada, Rizyinshi, Sarlic, Vlamma

<noinclude>{{clear}}{{last version link|Guild:Phaedreas Tears}}
----
<references/>
----

[[Category:Guilds|{{PAGENAME}}]]</noinclude>

Guild:Phaedreas Tears

2020-10-28T11:08:14Z

Moniq: Rewritten

{{Tabs
|bord=2px solid #{{ColorAtys|type=dark|group=ranger}}
|bg_frame=#{{ColorAtys|type=bg|group=ranger}}
|round=5em
|align_tab=center

|Tab-1={{3DText|text='''The Tears'''}}
|URL-1=Guild:Phaedreas Tears
|bg_Tab-1=#{{ColorAtys|type=light|group=ranger}}
|Pic-1=Phaedreas Tears.png

|Tab-2={{3DText|text='''OOC information'''}}
|URL-2=Guild:Phaedreas Tears/OOC
|bg_Tab-2=#{{ColorAtys|type=light|group=OOC}}
|Pic-2=Dummy.png
}}{{Guild
|name=Phaedrea's Tears
|Icon=Phaedreas Tears.png
|Leader= [[User:Itzy|Itzy]]
|Hall=[[Yrkanis (city)|Yrkanis]]
|Nation=none
|Faction=Neutral
|}}<noinclude>{{Trad
|DE=Gilde:Phaedreas Tears|DEs=5
|EN=Guild:Phaedreas Tears|ENs=0
|ES=Gremio:Phaedreas Tears|ESs=5
|FR=Guilde:Phaedreas Tears|FRs=1
|RU=Гильда:Phaedreas Tears|RUs=5
|palette=ranger
}}</noinclude>__TOC__

The Guild of Phaedreas Tears holds its center in [[Yrkanis]] near the Karavan Altar. It is open to all Homins of good well who are willing to abjure violence against other Homins and to aid those in need regardless of their beliefs. The Guild claims own allegiance to be neutral to factions and nations, its members have no religion. Some of the Guild members seek to become Rangers, but that is not required.

The Guild of Phaedreas Tears is currently lead by Guild leader [[User:Itzy|Itzy]]. Guild members are disallowed to fight with other homins however we know 2 OP incidents where the Guild was involved. The Guild is officially using English in communication with others. By the Guild register records the Guild controls 3 other Guilds, ''Itzy's Minions'', ''Shed Tears'' and ''Slight Risk''.

{{Quotation|''Mac'Od Bittty, former Guild Leader''|
Phaedrea's Tears is well alive and looking for a few good members. We are Nation and Faction Neutral, help all who have need, and do not fight other homins. We honor '''[[Tyneetryk]]''', of blessed memory, in that attitude. We expect members to work towards maximum Fame for all Nations and Factions. Working to become a Ranger Aspirant is desirable but not required. Being helpful to other homins, regardless of their affiliation, is expected, and use of guild resources to that end is encouraged. If this sounds good to you, contact any member of Phaedrea's Tears and we can discuss it.}}

==General Information==
''We offer assistance to any who ask it, but we assist, we do not lift up those who will not work to lift themselves. If you would join us be prepared to work hard to advance yourself.''
[[File:Pt lucio 1.png|right|thumb|450px|Guild event on 16th Aniversary of PT at Tyneetryk's memorial place, Virginia Falls]]
{{GuildGeneralInfo
|image=
|server=Atys
|land=[[Verdant Heights]]
|GH=[[Yrkanis (city)|Yrkanis]]
|FactionAlignment=Neutral
|RacialAlignment=Neutral
|AllowedRaces=All
|pvpStance=None
|rpStance=Semi
|website=
|}}
====Officials====
* '''✩ Leader:''' [[user:Itzy|Itzy]]
* '''✩ High Officers:''' Atanae, [[user:Bitttymacod|Mac'Od Bittty]], Ferishan, Fleetwood, Gabbystar, Hwinoree, Microgiant, [[User:Moniq|Moniq]], Rizyinshi and Sunray
* '''✩ Officers:''' Copesious, Estellar, Joelley, Joneyentee, Josemg, Milada, Rivatha, Sarlic and Vlamma

== History ==
Phaedreas Tears was founded in October, 2004. It was initially aligned as a Matis, Karavan, Guild for the purpose of guildhall space and teleports. However, it has always been willing to aid '''all''' Homins in need.

{{Quotation|''From the tale of Sumguy''|
Phaedrea arrived to look upon her young friends, noticed them leaving, and although joyful, wept, for such was the warmth of her heart for all Matis kind. And so in honour of this lady, the band of Matis bound in friendship and love for Phaedrea created the Guild that would be known henceforth as Phaedrea’s Tears … Each Tear being a Matis soul, to defend Yrkanis against evil, in all its forms.

Such is the essence of Tears. If you love King Yrkanis and the Lady Phaedrea, if you hold friendship dear above all else, then you already are a Tear at true heart. You know Life Is Beautiful, because you share it unasked. When the clouds grow dark and the rain sets in, your face turns high, to the sky. When they skitter and run before a strong wind, you'll grab a javing, by its feet, try to fly. Every snowfall makes a snowball, when you're cold you make a huddle. When you hear a plaintive cry you will, every time, reply. Before you know it, you've made another friend.

Such is the light of Jena which glows in every young homin, never let it blow out.

We came to the lush Verdant Heights to regrow the beautiful civilization destroyed by the kitin onslaught, and there is much to be relearnt. A Tear is expected to find their own place in this endeavour and help others to find theirs. Nothing is learned so well as that which a homin discovers for themselves, many new discoveries have been made when a fresh pair of eyes has looked over old ground.

A Tear must uphold the good name of the guild and help, if they can, whenever asked. Once a Tear has paid their respects to the Green Seeds, and as soon as they are able, they should be proud to perform their civic duty keeping the pathways of Majestic Gardens free from ragus and gingos. Weapons, amplifying gloves and picks should not be wielded in the guildhall, and footwear must be removed before entering; crafting tools may be used with caution, well away from the polished furnishings.
}}

===Tyneetryk's times===
The official alignment of Phaedrea's Tears was changed following the server crash that divided the ownership by GameForge and Winchgate. Shortly before upcoming split (2010) was the guild lead by Joneyentee and the guild claimed itself to be officially neutral while the Karavan allegiance was used only because of teleportation pacts. The neutral and anti-PvP stance of he Guild were set by Tyneetryk (around February 6th 2012<ref>[[User:Tyneetryk|Tyneetryk]]: [[Special:Contributions/Tyneetryk|contributions]]</ref>) , and after her departure for the Summerlands, kept by Ferishan and [[User:Mac'Od Bittty]].

{{Quotation|''Tyneetryk, former Guild Leader''|
Long ago the warriors of Phaedrea rose to fight the oppression of the Kitins. Much has changed since then and now the guild is primarily focused in aiding the newly arrived refugees on Silan and the Mainland to find a place for themselves on Atys.

Phaedrea's Tears is open to players with various interests. It boasts a friendly and supportive environment. Tears is the only actively recruiting guild which is completely neutral and all of the current active members are also completely neutral. The guild does not take sides in the Karavan-Kami conflict, however individual members are allowed to participate in PvP as they wish.

The guild does not actively invite or cajole players into joining, but we give unconditional help and assistance to whoever needs it and let them choose to join if they wish.

We are also active on Silan but we have a policy of refusing guild requests until a player has established a character on the mainland. We believe that players should have a chance to see the various guilds, discover what each one has to offer and so make an informed decision.

As already stated, the guild's main goal is to help new players on Atys, both on Silan and the Mainland. Roleplay is welcome but not mandatory.
}}
====Officials====
* '''✩ Leader:''' [[Tyneetryk]]
* '''✩ High Officers:''' Byrana, Ferishan, Joneyentee, Shadia,
* '''✩ Officers:''' Bryanna, Fyranna, Joelley, [[Teeneemai|Minimei]], Shadiaz

===15 years and first true neutral===
[[File:Screenshot 2017-04-23 002 Giselher.jpg|400px|thumb|Virginia falls. In memoriam [[Tyneetryk]]...]]
[[File:Mc'Od Bittty.jpg|64px|Thumb|left|Mc'Od Bittty]]
Times after Tyneetryk were years of holding the new spirit of the Guild. [[Teeneemai]] has established [[Guild:Tyneetryk's Tears|Tyneetryk's Tears]] to hold the beloved leader name and the Guild itself focus more on members quality than quantity. The leadership of [[user:Bitttymacod|Mac'Od Bittty]] has built small but solid members base that hold the legacy of Tyneetryk. ''15 years old and first <ref>''This statement is contested, but we are certainly the longest lasting.'' --Mac'Od Bittty</ref> of true neutral guilds in Atys.''

{{Quotation|''Mac'Od Bittty, former Guild Leader''|
...Much has changed since then. Now the guild is primarily focused in aiding the newly arrived refugees on Silan and the Mainland to find a place for themselves on Atys. Phaedrea's Tears is open to all homins who pledge to shun violence against other homins and keep a neutral attitude towards all Nations and both Powers. The guildhall is in Yrkanis for reasons related to our history.
}}
====Officials====
* '''✩ Leader:''' [[user:Bitttymacod|Mac'Od Bittty]]
* '''✩ High Officers:''' Ferishan, Fleetwood, Hwinoree, [[user:Itzy|Itzy]], Joneyentee, [[User:Moniq|Moniq]], Rivatha, Saija
* '''✩ Officers:''' Bitesized, Estellar, Joelley, Milada, Rizyinshi, Sarlic, Vlamma

<noinclude>{{clear}}{{last version link|Guild:Phaedreas Tears}}
----
<references/>
----

[[Category:Guilds|{{PAGENAME}}]]</noinclude>

Making evidence

2020-10-04T14:04:24Z

Moniq: /* VLC media player */ typo fix

{{WIP}}
{{Trad
|DE =The Test Team Handbook|DEs=5
|EN =The Test Team Handbook|ENs=0
|ES =The Test Team Handbook|ESs=5
|FR =The Test Team Handbook|FRs=5
|RU =The Test Team Handbook|RUs=5
|H =
|palette=Grey
}}

This document describes ways how to make evidence in form of screenshots or videos. It is mainly helpful and intended for members of the [[Test Team]] however it might be useful for for regular users as well, especially when they need to document game issues for a ticket or game forum post. The document is separated into three sections by client platform and, in case of video recording, is not meant as help with live streaming.

The Ryzom client itself contains feature to capture screenshots and this functionality is described in [[:Help:Screenshots|Screenshot help]] on this wiki.

=Windows=
Windows 10 has some support for needed features but in case of older version you will probably need to install 3rd part software.

==Screenshot==
The way how to take a screenshot of your desktop in most of recent versions of Windows is very easy. In case of older version it consists of two steps, first the screenshot will be copied into the clipboard, then you need to start an image editor and paste the content of the clipboard in. Most of procedures use the '''Print Screen''' (sometimes '''PrtScn''') key on your keyboard. It is located right to F12 key, above the Insert key.

[[File:Gamebar ui.png|thumb|150px|alt=Windows Game Bar interface|Windows Game Bar interface]]

===Build-in tools===
With Windows 8.1 and newer you have an easy way how to take a screenshot of your desktop, it will be automatically saved into '''Pictures''' folder in your home folder.
Press '''Win+Print Screen'''

The other way will work with Windows 98 or newer but might also work with Windows 95 (not tested). First copy the desktop screenshot into your clipboard:
Press '''Print Screen''' key
Then you need to open Microsoft Paint, a simple image editor that is default part of all Windows, and paste the content of your clipboard. You can however use any other bitmap image editor.
Execute '''mspaint''' command (or find application '''Paint''' / '''MS Paint''' in your '''Start Menu''')
Press '''Ctrl+V''' (or '''right-click''' in the drawing area and select '''Paste''')
Save the image into a file

===Windows Game Bar===
Microsoft Windows 10 has a build-in feature to capture screenshots of you application related to other gamer extensions. It however is not possible to capture the whole desktop and you need to start the application you want to capture first.
Press '''Win+Alt+Print Screen''' to take a screenshot
Press '''Win+G''' to display Game Bar and access options

===[https://en.wikipedia.org/wiki/Greenshot Greenshot]===
[[File:Greensgot settings.png|thumb|150px|alt=Greenshot screenshot tool preferences|Greenshot screenshot tool preferences]]
Another option is to use Greenshot, an open source screenshot tool for Windows. Install the application and start it, it will be hidden in the panel notification area along with other icons. This will work with any Windows version that is supported by this software.
Press '''Ctrl''' + '''Print Screen''' to capture whole desktop, then save it to a file

===[https://en.wikipedia.org/wiki/GIMP The GIMP]===
GNU Image Manipulation Program, a powerful tool to edit bitmap images in various formats. It also have an interface to capture desktop screenshots.
Choose '''File''' > '''Create''' > '''Screenshot''' from the main menu

==Video recording==
Latest Microsoft Windows 10 includes support for video recording. In case you are using any older version, you will probably need to use 3rd party software to do the job.

===Windows Game Bar===
Microsoft Windows 10 has a build-in feature to record video of you application related to other gamer extensions. It however is not possible to record the whole desktop and you need to start the application you want to record first.
Press '''Win+Alt+R''' to start or stop video recording
Press '''Win+G''' to display Game Bar and access recording options

===[https://en.wikipedia.org/wiki/VLC_media_player VLC media player]===
[[File:Vlc capture.png|thumb|150px|alt=VLC capture device settings|VLC capture device settings]]
VLC is open-source multimedia player and stream server application that can, along with many other functions, also record your desktop. This recording should work with every version of Windows in case you are able to install and run VLC, however it requires you to perform several steps:
1. Select '''Media''' > '''Convert/Save''' (or press '''Ctrl+R''')
2. Switch to '''Capture Device''' tab
3. Select '''Desktop''' from '''Capture mode''' drop down menu
4. Set '''Desired frame rate for the capture''' using the spin box to at least '''15''' f/s
5. Click '''Convert/Save''' button
6. Select '''Profile''' from the drop-down menu (or click preferences button to adjust video output)
7. Select '''Destination file''' clicking on '''Browse''' button
8. Click '''Start''' button to start recording
9. To stop recording click standard '''⏹''' (stop) button as if you stop video/audio playback

==Other tools==
[[File:Carnac preferences preview.png|thumb|150px|alt=Carnac preferences and preview|Carnac preferences and preview]]
There exist some additional tools and utilities that might help to make evidence for your (testing) report.

=== [http://carnackeys.com/ Carnac] ===
In some special cases it might be needed to also record keys that you press on your keyboard. You can use the this utility in combination with desktop video recording. It requires Windows 7 or newer and [https://www.microsoft.com/en-au/download/details.aspx?id=42643 Microsoft .NET Framework 4.5.2]

=Linux=
[[File:Screenshot capture.png|thumb|150px|alt=Linux screenshot capture interface|Linux screenshot capture interface]]
Most of end-user desktop Linux distributions come with various tools that can do the job. Some of them are already part of your desktop environment, other can be installed from your distribution package repository. It is not aim of this document to describe all existing utilities.

==Screenshot==
Most of Linux graphical environments have built-in a way how to capture desktop screenshots already. It is usually accessible by pressing the '''Print Screen''' (sometimes '''PrtScn''') key on your keyboard. It is located right to '''F12''' key, above the '''Insert''' key. In case that your environment does not support this feature, you can use one of many alternatives.

===Build-in tools===
Taking screenshot by pressing '''Print Screen''' will work in case you are using [https://en.wikipedia.org/wiki/Cinnamon_(desktop_environment) Cinnamon], [https://en.wikipedia.org/wiki/GNOME Gnome], [https://en.wikipedia.org/wiki/KDE_Plasma_5 KDE Plasma 5], [https://en.wikipedia.org/wiki/MATE_(software) MATE] or [https://en.wikipedia.org/wiki/Xfce Xfce] desktop. Please consult help (accessible usually by pressing '''F1''' key) for advanced options specific for your desktop environment. These are usually accessible by starting the application alone from menu or as an argument on the command line.
Press '''Print Screen''' key to take a screenshot

===[https://en.wikipedia.org/wiki/GIMP The GIMP]===
[[File:Gimp screenshot ui.png|thumb|150px|alt=GIMP interface to take screenshot|GIMP interface to take screenshot]]
GNU Image Manipulation Program, a powerful tool to edit images in various formats. It also have an interface to capture desktop screenshots.
Choose '''File''' > '''Create''' > '''Screenshot''' from the main menu

===[https://en.wikipedia.org/wiki/ImageMagick ImageMagick]===
A set of command line driven utilities for image manipulation. Consult the manual page page for more options.
Execute '''import -window root ~/file_name.png''' command to take screenshot of your desktop and save it to your home directory.

==Video recording==
[[File:Simplescreenrecorder.png|thumb|150px|alt=SimpleScreenRecorder window with input settings|SimpleScreenRecorder window with input settings]]
It might be important to record your activity in the game. It can help you to show a problem or describe a client behaviour to others. There exist various ways how to do this.

===[https://en.wikipedia.org/wiki/SimpleScreenRecorder SimpleScreenRecorder]===
It is a small but powerful tool to record a video of your desktop environment. It is a Qt-based free (libre) software that allows you to specify shortcut to start and stop recording and set many other options. As first you need to configure the utility and then it can wait in the notification area until you need it.
1. Press '''Continue''' button on first window
2. Set video and audio input options and click '''Continue''' (optionally create a profile)
3. Select output file manually or by clicking on '''Browse...''' button
4. Check '''Separate file per segment''' (every video sequence will be save in a separated file)
5. Set video and audio output options and click '''Continue''' (optionally create a profile)
6. Set '''Hotkey''' combination to start/stop recording
7. Click SimpleScreenRecorder icon in notification area to hide main window
Now the tool is configured and you can start and stop recording any time you need.
Press selected shortcut (hotkey) to start/stop recording, '''Ctrl+R''' by default

===byzanz===
Another option is to use '''byzanz''', a command line utility that will record your desktop as an animated GIF (Graphics Interchange Format) image. Please note that, by default, the record will suffer the format limitations with small colour palette because True color using separated image blocks is not supported. Please consult the manual page for more options and output formats.
Execute '''byzanz-record ~/file_name.gif''' to record your desktop and save it to your home directory.

=== OBS ===
For linux (but windows, macOS 10 too) OBS is a good solution too https://obsproject.com

==Other tools==
[[File:Screenkey preferences preview.png|thumb|150px|alt=Screenkey preferences and preview|Screenkey preferences and preview]]
There exist some additional tools and utilities that might help to make evidence for your (testing) report.

=== [https://www.thregr.org/~wavexx/software/screenkey/ Screenkey] ===
In some special cases it might be needed to also record keys that you press on your keyboard. You can use the this utility in combination with desktop video recording.

=macOS=
Apple macOS is very friendly to all multimedia and you will have several ways to make evidence with tools shipped with the system.

'''Note:''' Following information were not tested and are based on public Apple macOS documentation. In case you are using this system, please [[Help#Help_on_wiki|help]] with this document.

==Screenshot==
By default, macOS comes with several applications to take screenshots of your desktop.

===[https://support.apple.com/en-us/HT201361 Screenshot app]===
The easiest way how to take a screenshot of your current desktop and let it be saved on your desktop is
Press '''Shift + Command ⌘ + 3''' and wait a moment before it is saved on your desktop

===[https://en.wikipedia.org/wiki/Grab_(software) Grab]===
Grab is another application that you can use to take screenshots of your desktop. You can find it in '''Applications''' > '''Utilities''' > '''Grab'''. When you see Grab menu...
Select '''Capture''' > '''Screen''' (or press '''Shift + Command ⌘ + W''')
Click somewhere out of the dialog window

==Video recording==
Same as in case of screenshots, macOS comes with several ways how to record your desktop.

===Mojave and newer===
With macOS Mojave or newer there is a very easy way how to record your desktop or its part.
Press '''Shift + Command ⌘ + 5''' to see bar with all possible options
Select appropriate button and click on a screen to start recording (or click '''Record''' button on the bar)

===[https://en.wikipedia.org/wiki/QuickTime QuickTime Player]===
You can use the QuickTime Player on macOS systems older than Mojave.
Select '''File''' > '''New Screen Recording'''
Click the red button in the middle of the window
Click anywhere on the screen to start recording
Click black stop button in notification area of the menu bar to stop recording (or press '''Command ⌘ + Ctrl + Esc''')

{{Portal|Forge}}
[[Category:Test|Test team]]
[[Category:Tutorials|Test team]]
[[Category:Testing Team]]
[[Category:Ryzom Team]]
[[Category:Test]]
[[Category:Tutorials]]

Making evidence

2020-10-04T14:01:23Z

Moniq: /* Build-in tools */ +save file instruction

{{WIP}}
{{Trad
|DE =The Test Team Handbook|DEs=5
|EN =The Test Team Handbook|ENs=0
|ES =The Test Team Handbook|ESs=5
|FR =The Test Team Handbook|FRs=5
|RU =The Test Team Handbook|RUs=5
|H =
|palette=Grey
}}

This document describes ways how to make evidence in form of screenshots or videos. It is mainly helpful and intended for members of the [[Test Team]] however it might be useful for for regular users as well, especially when they need to document game issues for a ticket or game forum post. The document is separated into three sections by client platform and, in case of video recording, is not meant as help with live streaming.

The Ryzom client itself contains feature to capture screenshots and this functionality is described in [[:Help:Screenshots|Screenshot help]] on this wiki.

=Windows=
Windows 10 has some support for needed features but in case of older version you will probably need to install 3rd part software.

==Screenshot==
The way how to take a screenshot of your desktop in most of recent versions of Windows is very easy. In case of older version it consists of two steps, first the screenshot will be copied into the clipboard, then you need to start an image editor and paste the content of the clipboard in. Most of procedures use the '''Print Screen''' (sometimes '''PrtScn''') key on your keyboard. It is located right to F12 key, above the Insert key.

[[File:Gamebar ui.png|thumb|150px|alt=Windows Game Bar interface|Windows Game Bar interface]]

===Build-in tools===
With Windows 8.1 and newer you have an easy way how to take a screenshot of your desktop, it will be automatically saved into '''Pictures''' folder in your home folder.
Press '''Win+Print Screen'''

The other way will work with Windows 98 or newer but might also work with Windows 95 (not tested). First copy the desktop screenshot into your clipboard:
Press '''Print Screen''' key
Then you need to open Microsoft Paint, a simple image editor that is default part of all Windows, and paste the content of your clipboard. You can however use any other bitmap image editor.
Execute '''mspaint''' command (or find application '''Paint''' / '''MS Paint''' in your '''Start Menu''')
Press '''Ctrl+V''' (or '''right-click''' in the drawing area and select '''Paste''')
Save the image into a file

===Windows Game Bar===
Microsoft Windows 10 has a build-in feature to capture screenshots of you application related to other gamer extensions. It however is not possible to capture the whole desktop and you need to start the application you want to capture first.
Press '''Win+Alt+Print Screen''' to take a screenshot
Press '''Win+G''' to display Game Bar and access options

===[https://en.wikipedia.org/wiki/Greenshot Greenshot]===
[[File:Greensgot settings.png|thumb|150px|alt=Greenshot screenshot tool preferences|Greenshot screenshot tool preferences]]
Another option is to use Greenshot, an open source screenshot tool for Windows. Install the application and start it, it will be hidden in the panel notification area along with other icons. This will work with any Windows version that is supported by this software.
Press '''Ctrl''' + '''Print Screen''' to capture whole desktop, then save it to a file

===[https://en.wikipedia.org/wiki/GIMP The GIMP]===
GNU Image Manipulation Program, a powerful tool to edit bitmap images in various formats. It also have an interface to capture desktop screenshots.
Choose '''File''' > '''Create''' > '''Screenshot''' from the main menu

==Video recording==
Latest Microsoft Windows 10 includes support for video recording. In case you are using any older version, you will probably need to use 3rd party software to do the job.

===Windows Game Bar===
Microsoft Windows 10 has a build-in feature to record video of you application related to other gamer extensions. It however is not possible to record the whole desktop and you need to start the application you want to record first.
Press '''Win+Alt+R''' to start or stop video recording
Press '''Win+G''' to display Game Bar and access recording options

===[https://en.wikipedia.org/wiki/VLC_media_player VLC media player]===
[[File:Vlc capture.png|thumb|150px|alt=VLC capture device settings|VLC capture device settings]]
VLC is open-source multimedia player and stream server application that can, along with many other functions, also record your desktop. This recording should work with every version of Windows in case you are able to install and run VLC, however it requires you to perform several steps:
1. Select '''Media''' > '''Convert/Save''' (or press '''Ctrl+R''')
2. Switch to '''Capture Device''' tab
3. Select '''Desktop''' from '''Capture mode''' drop down menu
4. Set '''Desired frame rate for the capture''' using the spin box to at least '''15''' f/s
5. Click '''Convert/Save''' button
6. Select '''Profile''' from the drop-down menu (or click preferences button to adjust video output)
7. Select '''Destination file''' vlivking on '''Browse''' button
8. Click '''Start''' button to start recording
9. To stop recording click standard '''⏹''' (stop) button as if you stop video/audio playback

==Other tools==
[[File:Carnac preferences preview.png|thumb|150px|alt=Carnac preferences and preview|Carnac preferences and preview]]
There exist some additional tools and utilities that might help to make evidence for your (testing) report.

=== [http://carnackeys.com/ Carnac] ===
In some special cases it might be needed to also record keys that you press on your keyboard. You can use the this utility in combination with desktop video recording. It requires Windows 7 or newer and [https://www.microsoft.com/en-au/download/details.aspx?id=42643 Microsoft .NET Framework 4.5.2]

=Linux=
[[File:Screenshot capture.png|thumb|150px|alt=Linux screenshot capture interface|Linux screenshot capture interface]]
Most of end-user desktop Linux distributions come with various tools that can do the job. Some of them are already part of your desktop environment, other can be installed from your distribution package repository. It is not aim of this document to describe all existing utilities.

==Screenshot==
Most of Linux graphical environments have built-in a way how to capture desktop screenshots already. It is usually accessible by pressing the '''Print Screen''' (sometimes '''PrtScn''') key on your keyboard. It is located right to '''F12''' key, above the '''Insert''' key. In case that your environment does not support this feature, you can use one of many alternatives.

===Build-in tools===
Taking screenshot by pressing '''Print Screen''' will work in case you are using [https://en.wikipedia.org/wiki/Cinnamon_(desktop_environment) Cinnamon], [https://en.wikipedia.org/wiki/GNOME Gnome], [https://en.wikipedia.org/wiki/KDE_Plasma_5 KDE Plasma 5], [https://en.wikipedia.org/wiki/MATE_(software) MATE] or [https://en.wikipedia.org/wiki/Xfce Xfce] desktop. Please consult help (accessible usually by pressing '''F1''' key) for advanced options specific for your desktop environment. These are usually accessible by starting the application alone from menu or as an argument on the command line.
Press '''Print Screen''' key to take a screenshot

===[https://en.wikipedia.org/wiki/GIMP The GIMP]===
[[File:Gimp screenshot ui.png|thumb|150px|alt=GIMP interface to take screenshot|GIMP interface to take screenshot]]
GNU Image Manipulation Program, a powerful tool to edit images in various formats. It also have an interface to capture desktop screenshots.
Choose '''File''' > '''Create''' > '''Screenshot''' from the main menu

===[https://en.wikipedia.org/wiki/ImageMagick ImageMagick]===
A set of command line driven utilities for image manipulation. Consult the manual page page for more options.
Execute '''import -window root ~/file_name.png''' command to take screenshot of your desktop and save it to your home directory.

==Video recording==
[[File:Simplescreenrecorder.png|thumb|150px|alt=SimpleScreenRecorder window with input settings|SimpleScreenRecorder window with input settings]]
It might be important to record your activity in the game. It can help you to show a problem or describe a client behaviour to others. There exist various ways how to do this.

===[https://en.wikipedia.org/wiki/SimpleScreenRecorder SimpleScreenRecorder]===
It is a small but powerful tool to record a video of your desktop environment. It is a Qt-based free (libre) software that allows you to specify shortcut to start and stop recording and set many other options. As first you need to configure the utility and then it can wait in the notification area until you need it.
1. Press '''Continue''' button on first window
2. Set video and audio input options and click '''Continue''' (optionally create a profile)
3. Select output file manually or by clicking on '''Browse...''' button
4. Check '''Separate file per segment''' (every video sequence will be save in a separated file)
5. Set video and audio output options and click '''Continue''' (optionally create a profile)
6. Set '''Hotkey''' combination to start/stop recording
7. Click SimpleScreenRecorder icon in notification area to hide main window
Now the tool is configured and you can start and stop recording any time you need.
Press selected shortcut (hotkey) to start/stop recording, '''Ctrl+R''' by default

===byzanz===
Another option is to use '''byzanz''', a command line utility that will record your desktop as an animated GIF (Graphics Interchange Format) image. Please note that, by default, the record will suffer the format limitations with small colour palette because True color using separated image blocks is not supported. Please consult the manual page for more options and output formats.
Execute '''byzanz-record ~/file_name.gif''' to record your desktop and save it to your home directory.

=== OBS ===
For linux (but windows, macOS 10 too) OBS is a good solution too https://obsproject.com

==Other tools==
[[File:Screenkey preferences preview.png|thumb|150px|alt=Screenkey preferences and preview|Screenkey preferences and preview]]
There exist some additional tools and utilities that might help to make evidence for your (testing) report.

=== [https://www.thregr.org/~wavexx/software/screenkey/ Screenkey] ===
In some special cases it might be needed to also record keys that you press on your keyboard. You can use the this utility in combination with desktop video recording.

=macOS=
Apple macOS is very friendly to all multimedia and you will have several ways to make evidence with tools shipped with the system.

'''Note:''' Following information were not tested and are based on public Apple macOS documentation. In case you are using this system, please [[Help#Help_on_wiki|help]] with this document.

==Screenshot==
By default, macOS comes with several applications to take screenshots of your desktop.

===[https://support.apple.com/en-us/HT201361 Screenshot app]===
The easiest way how to take a screenshot of your current desktop and let it be saved on your desktop is
Press '''Shift + Command ⌘ + 3''' and wait a moment before it is saved on your desktop

===[https://en.wikipedia.org/wiki/Grab_(software) Grab]===
Grab is another application that you can use to take screenshots of your desktop. You can find it in '''Applications''' > '''Utilities''' > '''Grab'''. When you see Grab menu...
Select '''Capture''' > '''Screen''' (or press '''Shift + Command ⌘ + W''')
Click somewhere out of the dialog window

==Video recording==
Same as in case of screenshots, macOS comes with several ways how to record your desktop.

===Mojave and newer===
With macOS Mojave or newer there is a very easy way how to record your desktop or its part.
Press '''Shift + Command ⌘ + 5''' to see bar with all possible options
Select appropriate button and click on a screen to start recording (or click '''Record''' button on the bar)

===[https://en.wikipedia.org/wiki/QuickTime QuickTime Player]===
You can use the QuickTime Player on macOS systems older than Mojave.
Select '''File''' > '''New Screen Recording'''
Click the red button in the middle of the window
Click anywhere on the screen to start recording
Click black stop button in notification area of the menu bar to stop recording (or press '''Command ⌘ + Ctrl + Esc''')

{{Portal|Forge}}
[[Category:Test|Test team]]
[[Category:Tutorials|Test team]]
[[Category:Testing Team]]
[[Category:Ryzom Team]]
[[Category:Test]]
[[Category:Tutorials]]

Template:Moniq's Apps

2020-09-25T21:10:48Z

Moniq: Deeplist description

<noinclude>{{Trad
|DE = Moniq's Apps|DEs= 1
|EN = Moniq's Apps|ENs= 0
|ES = Moniq's Apps|ESs=1
|FR = Moniq's Apps |FRs= 0
|RU = Moniq's Apps|RUs= 1
|H =
|palette=
|ref=
|com=
}}</noinclude>
<includeonly>{| class="wikitable"
|-
! Icon !! Application !! AppZone !! Additional details
|-
|[[File:BagApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/bagapp/?sekce=document&klic=bagapp Bag App]''' 0.6 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1977 /appzone 1977]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1977 Install] || Tool to browse inventory cache obtained from character and/or guild API. URL: http://beta.kdyne.net/rygreg/STABLE/bagapp/
|-
|[[File:Bbg ico.png]]|| '''Blabla Game''' ''(part of Lang App)'' || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2413 /appzone 2413]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2413 Install] || A little translation game with Atys languages URL: http://beta.kdyne.net/rygreg/STABLE/langapp/?sekce=bbg
|-
|[[File:Bbt ico.png]]|| '''Blablator''' ''(part of Lang App)'' || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2414 /appzone 2414]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2414 Install] || Blablator, dummy brute-force translator to and from Atys languages URL: http://beta.kdyne.net/rygreg/STABLE/langapp/?sekce=blablator
|-
|[[File:Book of Guilds-icon.png]]|| '''Book of Guids''' first release || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1960 /appzone 1960]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1960 Install] || Livre des Guildes d'Atys - Libro de Gremios - Buch der Gilden URL: http://beta.kdyne.net/rygreg/STABLE/bog_first/
|-
|[[File:Deeplist.png|32px]]|| '''DeepList''' 0.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2567 /appzone 2567]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1977 Install] || Application manage specific Atys terms with dictionary export API URL: http://beta.kdyne.net/rygreg/STABLE/deeplist/
|-
|[[File:FameTracker-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/fameapp/?sekce=document&klic=fameapp Fame Tracker]''' 0.9.2 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2132 /appzone 2132]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2132 Install] || Suivi de la Renommée - Ruhm-Übersicht - Rastreador de Fama URL: http://beta.kdyne.net/rygreg/STABLE/fameapp/
|-
|[[File:LangApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/langapp/?sekce=document&klic=langapp Lang App]''' 0.9.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2135 /appzone 2135]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2135 Install] || Interface to translate applications and browse old Blablatys dictionary URL: http://beta.kdyne.net/rygreg/STABLE/langapp/
|-
|[[File:LevelTracker-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/levelapp/?sekce=document&klic=levelapp Level Tracker]''' 0.5 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2324 /appzone 2324]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2324 Install] || Level tracker helps you to track your progress in each skill level. URL: http://beta.kdyne.net/rygreg/STABLE/levelapp/
|-
|[[File:LetterApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/rygreg/?sekce=document&klic=letterapp Letter App]''' 0.2 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2585 /appzone 2585]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2585 Install] || Tool to generate custom looking letter images for the role-play purposes. URL: http://beta.kdyne.net/rygreg/STABLE/letterapp/
|-
|[[File:RyGREg-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/bagapp/?sekce=document&klic=rygreg RyGReg]''' 0.9.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1947 /appzone 1947]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1947 Install] || Ryzom Guild Registry URL: http://beta.kdyne.net/rygreg/STABLE/rygreg/
|-
|[[File:Sluha-icon.png]]|| '''Sluha, the merchant''' - || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1971 /appzone 1971]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1971 Install] || DISFUNCT! Trading with a nomad merchant traveling around Atys URL: http://beta.kdyne.net/rygreg/DEVEL/sluha/
|}</includeonly>
<noinclude>
This template displays the table of [[User:Moniq/OOC|Moniq's Apps]] information table. 
== Usage ==
<code><nowiki>{{Moniq's Apps}}</nowiki></code> 
 
which gives: 
{{Moniq's Apps}}
[[Category:User Templates]]</noinclude>

Template:Moniq's Apps

2020-09-25T20:59:55Z

Moniq: bog url fixed

<noinclude>{{Trad
|DE = Kitin-Nester |DEs= 1
|EN = Kitin Nests |ENs= 0
|ES = Nidos de Kitin |ESs=1
|FR = Nids de Kitins |FRs= 0
|RU = Китинские гнезда |RUs= 1
|H =
|palette=
|ref=
|com=
}}</noinclude>
<includeonly>{| class="wikitable"
|-
! Icon !! Application !! AppZone !! Additional details
|-
|[[File:BagApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/bagapp/?sekce=document&klic=bagapp Bag App]''' 0.6 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1977 /appzone 1977]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1977 Install] || Tool to browse inventory cache obtained from character and/or guild API. URL: http://beta.kdyne.net/rygreg/STABLE/bagapp/
|-
|[[File:Bbg ico.png]]|| '''Blabla Game''' ''(part of Lang App)'' || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2413 /appzone 2413]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2413 Install] || A little translation game with Atys languages URL: http://beta.kdyne.net/rygreg/STABLE/langapp/?sekce=bbg
|-
|[[File:Bbt ico.png]]|| '''Blablator''' ''(part of Lang App)'' || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2414 /appzone 2414]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2414 Install] || Blablator, dummy brute-force translator to and from Atys languages URL: http://beta.kdyne.net/rygreg/STABLE/langapp/?sekce=blablator
|-
|[[File:Book of Guilds-icon.png]]|| '''Book of Guids''' first release || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1960 /appzone 1960]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1960 Install] || Livre des Guildes d'Atys - Libro de Gremios - Buch der Gilden URL: http://beta.kdyne.net/rygreg/STABLE/bog_first/
|-
|[[File:Deeplist.png|32px]]|| '''DeepList''' 0.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2567 /appzone 2567]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1977 Install] || An App manage specific tersm for additional automatic translation dicxtionary URL: http://beta.kdyne.net/rygreg/STABLE/deeplist/
|-
|[[File:FameTracker-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/fameapp/?sekce=document&klic=fameapp Fame Tracker]''' 0.9.2 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2132 /appzone 2132]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2132 Install] || Suivi de la Renommée - Ruhm-Übersicht - Rastreador de Fama URL: http://beta.kdyne.net/rygreg/STABLE/fameapp/
|-
|[[File:LangApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/langapp/?sekce=document&klic=langapp Lang App]''' 0.9.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2135 /appzone 2135]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2135 Install] || Interface to translate applications and browse old Blablatys dictionary URL: http://beta.kdyne.net/rygreg/STABLE/langapp/
|-
|[[File:LevelTracker-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/levelapp/?sekce=document&klic=levelapp Level Tracker]''' 0.5 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2324 /appzone 2324]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2324 Install] || Level tracker helps you to track your progress in each skill level. URL: http://beta.kdyne.net/rygreg/STABLE/levelapp/
|-
|[[File:LetterApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/rygreg/?sekce=document&klic=letterapp Letter App]''' 0.2 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2585 /appzone 2585]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2585 Install] || Tool to generate custom looking letter images for the role-play purposes. URL: http://beta.kdyne.net/rygreg/STABLE/letterapp/
|-
|[[File:RyGREg-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/bagapp/?sekce=document&klic=rygreg RyGReg]''' 0.9.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1947 /appzone 1947]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1947 Install] || Ryzom Guild Registry URL: http://beta.kdyne.net/rygreg/STABLE/rygreg/
|-
|[[File:Sluha-icon.png]]|| '''Sluha, the merchant''' - || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1971 /appzone 1971]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1971 Install] || DISFUNCT! Trading with a nomad merchant traveling around Atys URL: http://beta.kdyne.net/rygreg/DEVEL/sluha/
|}</includeonly>
<noinclude>
This template displays the table of [[User:Moniq/OOC|Moniq's Apps]]information table. 
== Usage ==
<code><nowiki>{{Moniq's Apps}}</nowiki></code> 
 
which gives: 
{{Moniq's Apps}}
[[Category:User Templates]]</noinclude>

Template:Moniq's Apps

2020-09-25T20:57:50Z

Moniq: minor corrections

<noinclude>{{Trad
|DE = Kitin-Nester |DEs= 1
|EN = Kitin Nests |ENs= 0
|ES = Nidos de Kitin |ESs=1
|FR = Nids de Kitins |FRs= 0
|RU = Китинские гнезда |RUs= 1
|H =
|palette=
|ref=
|com=
}}</noinclude>
<includeonly>{| class="wikitable"
|-
! Icon !! Application !! AppZone !! Additional details
|-
|[[File:BagApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/bagapp/?sekce=document&klic=bagapp Bag App]''' 0.6 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1977 /appzone 1977]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1977 Install] || Tool to browse inventory cache obtained from character and/or guild API. URL: http://beta.kdyne.net/rygreg/STABLE/bagapp/
|-
|[[File:Bbg ico.png]]|| '''Blabla Game''' ''(part of Lang App)'' || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2413 /appzone 2413]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2413 Install] || A little translation game with Atys languages URL: http://beta.kdyne.net/rygreg/STABLE/langapp/?sekce=bbg
|-
|[[File:Bbt ico.png]]|| '''Blablator''' ''(part of Lang App)'' || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2414 /appzone 2414]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2414 Install] || Blablator, dummy brute-force translator to and from Atys languages URL: http://beta.kdyne.net/rygreg/STABLE/langapp/?sekce=blablator
|-
|[[File:Book of Guilds-icon.png]]|| '''Book of Guids''' first release || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1960 /appzone 1960]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1960 Install] || Livre des Guildes d'Atys - Libro de Gremios - Buch der Gilden URL: http://beta.kdyne.net/rygreg/STABLE/bof_first/
|-
|[[File:Deeplist.png|32px]]|| '''DeepList''' 0.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2567 /appzone 2567]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1977 Install] || An App manage specific tersm for additional automatic translation dicxtionary URL: http://beta.kdyne.net/rygreg/STABLE/deeplist/
|-
|[[File:FameTracker-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/fameapp/?sekce=document&klic=fameapp Fame Tracker]''' 0.9.2 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2132 /appzone 2132]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2132 Install] || Suivi de la Renommée - Ruhm-Übersicht - Rastreador de Fama URL: http://beta.kdyne.net/rygreg/STABLE/fameapp/
|-
|[[File:LangApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/langapp/?sekce=document&klic=langapp Lang App]''' 0.9.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2135 /appzone 2135]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2135 Install] || Interface to translate applications and browse old Blablatys dictionary URL: http://beta.kdyne.net/rygreg/STABLE/langapp/
|-
|[[File:LevelTracker-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/levelapp/?sekce=document&klic=levelapp Level Tracker]''' 0.5 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2324 /appzone 2324]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2324 Install] || Level tracker helps you to track your progress in each skill level. URL: http://beta.kdyne.net/rygreg/STABLE/levelapp/
|-
|[[File:LetterApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/rygreg/?sekce=document&klic=letterapp Letter App]''' 0.2 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2585 /appzone 2585]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2585 Install] || Tool to generate custom looking letter images for the role-play purposes. URL: http://beta.kdyne.net/rygreg/STABLE/letterapp/
|-
|[[File:RyGREg-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/bagapp/?sekce=document&klic=rygreg RyGReg]''' 0.9.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1947 /appzone 1947]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1947 Install] || Ryzom Guild Registry URL: http://beta.kdyne.net/rygreg/STABLE/rygreg/
|-
|[[File:Sluha-icon.png]]|| '''Sluha, the merchant''' - || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1971 /appzone 1971]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1971 Install] || DISFUNCT! Trading with a nomad merchant traveling around Atys URL: http://beta.kdyne.net/rygreg/DEVEL/sluha/
|}</includeonly>
<noinclude>
This template displays the table of [[User:Moniq/OOC|Moniq's Apps]]information table. 
== Usage ==
<code><nowiki>{{Moniq's Apps}}</nowiki></code> 
 
which gives: 
{{Moniq's Apps}}
[[Category:User Templates]]</noinclude>

User:Moniq/OOC

2020-09-25T20:54:14Z

Moniq: /* In-game applications */ use template for lsit of apps

{{Tabs
|bord=2px solid #{{ColorAtys|type=dark|group=ranger}}
|bg_frame=#{{ColorAtys|type=bg|group=OOC}}
|round=5em
|align_tab=center

|Tab-1={{3DText|text='''Profile'''}}
|URL-1=User:Moniq
|bg_Tab-1=#{{ColorAtys|type=bg|group=ranger}}
|Pic-1=Phaedreas Tears.png

|Tab-2={{3DText|text='''OOC notes'''}}
|URL-2=User:Moniq/OOC
|bg_Tab-2=#{{ColorAtys|type=bg|group=OOC}}
|Pic-2=Ico_task_rite.png
}}

{{#babel:cs|en-3|sk-3|de-1|fr-0|ru-0}}

=Ryzom Forge=
I am a member of [[:Portal:Forge|Ryzom Forge]] since about 2017. I am mainly involved in the [[Test Team]] as a tester, coordinator and encyclopatyst and I am also member of the [[Project Bugs]]. Main content of my work is to hunt and track Ryzom issues. I also work on following documentation for the Test team:
* [[The_Test_Team_Handbook|Test Team Handbook]], a general handbook for (new) testers
* [[Test Team roles]] that describes various roles a Test team member can occupy
* [[How to request new testing]] that provides information about how request the Test team to start new testing
* [[Making evidence]] with general information about how to make evidence for (testing) reports
* [[User:Moniq/OOC/DeppL_List|DeepL translation exceptions]] too coordinate creation of the list along [https://board.ryzom.com/?controller=TaskViewController&action=show&task_id=10473 task #10473]

=In-game applications=
I have created following application you can install from the App Zone:
{{Moniq's Apps}}

=Contact=
* In-Game chat: <code>/t Moniq</code> (when online)
* Ryzom Chat:
** [https://chat.ryzom.com/direct/Moniq private conversation] to be used in regular web browser
** <code>/t ~Moniq</code> to contact me while you are in-game
* My [[User talk:Moniq|Discussion Page]]
{{clear}}

Template:Moniq's Apps

2020-09-25T20:53:25Z

Moniq: table rewritten

<noinclude>{{Trad
|DE = Kitin-Nester |DEs= 1
|EN = Kitin Nests |ENs= 0
|ES = Nidos de Kitin |ESs=1
|FR = Nids de Kitins |FRs= 0
|RU = Китинские гнезда |RUs= 1
|H =
|palette=
|ref=
|com=
}}</noinclude>
<includeonly>{| class="wikitable"
|-
! Icon !! Application !! AppZone !! Additional details
|-
|[[File:BagApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/bagapp/?sekce=document&klic=bagapp Bag App]''' 0.6 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1977 /appzone 1977]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1977 Install] || Tool to browse inventory cache obtained from character and/or guild API. URL: http://beta.kdyne.net/rygreg/STABLE/bagapp/
|-
|[[File:Bbg ico.png]]|| '''Blabla Game''' ''(part of LangApp)'' || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2413 /appzone 2413]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2413 Install] || A little translation game with Atys languages URL: http://beta.kdyne.net/rygreg/STABLE/langapp/?sekce=bbg
|-
|[[File:Bbt ico.png]]|| '''Blablator''' ''(part of LangApp)'' || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2414 /appzone 2414]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2414 Install] || Blablator, dummy brute-force translator to and from Atys languages URL: http://beta.kdyne.net/rygreg/STABLE/langapp/?sekce=blablator
|-
|[[File:Book of Guilds-icon.png]]|| '''Book of Guids''' first release || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1960 /appzone 1960]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1960 Install] || Livre des Guildes d'Atys - Libro de Gremios - Buch der Gilden URL: http://beta.kdyne.net/rygreg/STABLE/bof_first/
|-
|[[File:Deeplist.png|32px]]|| '''DeepList''' 0.1a9 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2567 /appzone 2567]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1977 Install] || An App manage specific tersm for additional automatic translation dicxtionary URL: http://beta.kdyne.net/rygreg/STABLE/deeplist/
|-
|[[File:FameTracker-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/fameapp/?sekce=document&klic=fameapp Fame Tracker]''' 0.9.2 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2132 /appzone 2132]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2132 Install] || Suivi de la Renommée - Ruhm-Übersicht - Rastreador de Fama URL: http://beta.kdyne.net/rygreg/STABLE/fameapp/
|-
|[[File:LangApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/langapp/?sekce=document&klic=langapp Lang app]''' 0.9.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2135 /appzone 2135]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2135 Install] || Interface to translate applications and browse old Blablatys dictionary URL: http://beta.kdyne.net/rygreg/STABLE/langapp/
|-
|[[File:LevelTracker-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/levelapp/?sekce=document&klic=levelapp Level Tracker]''' 0.5 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2324 /appzone 2324]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2324 Install] || Level tracker helps you to track your progress in each skill level. URL: http://beta.kdyne.net/rygreg/STABLE/levelapp/
|-
|[[File:LetterApp-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/rygreg/?sekce=document&klic=letterapp Letter app]''' 0.2 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=2585 /appzone 2585]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=2585 Install] || Tool to generate custom looking letter images for the role-play purposes. URL: http://beta.kdyne.net/rygreg/STABLE/letterapp/
|-
|[[File:RyGREg-icon.png]]|| '''[http://beta.kdyne.net/rygreg/STABLE/bagapp/?sekce=document&klic=rygreg RyGReg]''' 0.9.1 || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1947 /appzone 1947]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1947 Install] || Ryzom Guild Registry URL: http://beta.kdyne.net/rygreg/STABLE/rygreg/
|-
|[[File:Sluha-icon.png]]|| '''Sluha, the merchant''' - || '''[https://app.ryzom.com/index.php?action=launch_app&appid=1971 /appzone 1971]''' [https://app.ryzom.com/index.php?action=add_user_app&app_id=1971 Install] || DISFUNCT! Trading with a nomad merchant traveling around Atys URL: http://beta.kdyne.net/rygreg/DEVEL/sluha/
|}</includeonly>
<noinclude>
This template displays the table of [[User:Moniq/OOC|Moniq's Apps]]information table. 
== Usage ==
<code><nowiki>{{Moniq's Apps}}</nowiki></code> 
 
which gives: 
{{Moniq's Apps}}
[[Category:User Templates]]</noinclude>

Lucenthead Hurst

2020-09-06T14:47:44Z

Moniq: internal links fixed

{{Locality}}

The '''Lucenthead Hurst''' is a locality of [[Outlaw Canyon]], in the [[Burning Desert]]

Connected to the [[Imperial Dunes]] through two bridges built by the [[Fyros]] over the Outlaw Canyon; it is the only place in [[Atys]] where you can find [[Papalexi|papalexis]].

==Notes==

An “hurst” is a territory or a geological block that has been raised by rifts. The Lucenthead Hurst is a good example, forming a natural ridge overlooking the Outlaw Canyon.

The term “lucenthead”, on the other hand, remains of mysterious origin.

[[Category:Localities]]]
[[Category:Geographical Curiosities]]

New Billing Service

2020-08-26T21:38:03Z

Moniq: /* Who to contact in case of a billing problem? */ margin left for last entry, but maybe use * list instead?

<noinclude>{{Trad
|DE=Neuer Abrechnungsservice
|ES=Nuevo servicio de facturación
|EN=New Billing Service
|FR=Nouveau service de facturation
|RU=Новая биллинговая услуга
}}</noinclude>

[[file:Ryzom logo.png|center]]

<center><big><big><big>'''New billing system'''</big></big></big></center>

Ryzom is getting a new billing system offering more possibilities in terms of subscription duration and means of payment. The system accessible from its website [https://www.ryzom.com/ https://www.ryzom.com].

= Durations of subscription and rates =

=== Premium Rates ===

{| style="border-spacing:0;margin:auto;width:17cm;"
|-
| align=center style="background-color:transparent;border-top:0.5pt solid #000000;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:none;padding:0.097cm;color:#000000;" | '''Xsolla''''' (lower rates for 12 months) *''
| align=center style="background-color:transparent;border-top:0.5pt solid #000000;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:none;padding:0.097cm;color:#000000;" | '''Paypal'' '''(tariffs 3, 6 and 12 months down)''
| align=center style="background-color:transparent;border:0.5pt solid #000000;padding:0.097cm;color:#000000;" | '''Steam '''''(unchanged rates)''
|-
| style="background-color:transparent;border-top:none;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:none;padding:0.097cm;" | 1 month: 7.95€

3 months: 22.50€

6 months: 41.70€

<div style="color:#000000;">12 months: 59.00€</div>
| style="background-color:transparent;border-top:none;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:none;padding:0.097cm;" | 1 month: 8.95€

3 months: 22.50€

6 months: 41.70€

<div style="color:#000000;">12 months: 59.00€</div>
| style="background-color:transparent;border-top:none;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:0.5pt solid #000000;padding:0.097cm;" | 1 month: 9.98€

3 months: 27.98€

6 months: 52.95€

<div style="color:#000000;">12 months: 96.95€</div>
|-
|}

<div style="color:#000000;"><nowiki>* </nowiki>Please note, however, that some new payment methods offered by Xsolla cause an additional cost, as it is already the case for Paypal and Steam.</div>

=== Short duration Premium rates ===

The Premium rates for short periods are being introduced.

{| style="border-spacing:0;margin:auto;width:17cm;"
|-
| align=center style="background-color:transparent;border-top:0.5pt solid #000000;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:none;padding:0.097cm;color:#000000;" | '''Xsolla'''
| align=center style="background-color:transparent;border:0.5pt solid #000000;padding:0.097cm;color:#000000;" | '''Paypal'''
|-
| style="background-color:transparent;border-top:none;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:none;padding:0.097cm;" | 2 days: 1.5€

3 days: 2€

5 days: 2.5€

<div style="color:#000000;">7 days: 3€</div>
| style="background-color:transparent;border-top:none;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:0.5pt solid #000000;padding:0.097cm;" | 2 days: 2€

3 days: 2.5€

5 days: 3€

<div style="color:#000000;">7 days: 3.5€</div>

|-
|}
= Premium advantages =

<div style="text-align:center;">[[File:New Billing image5.png|center|512px]]</div>

= Payment Options =

[[File:New Billing image1.png|center|512px]]

The Premium access offers several payment options: * '''Recurring payments''' (via '''[https://xsolla.com/ Xsolla]'''), with automatic renewal each 1, 3, 6 or 12 months.
* '''One-time payments '''(''via'' '''[https://xsolla.com/ Xsolla]''') : punctual payments of 1, 3, 6 or 12 months, which can be cumulated with other one-time payments.
* '''Short duration one-time payments''' (''via'' '''[https://xsolla.com/ Xsolla]''') : punctual payments of 1, 2, 5 or 7 days, which can be cumulated with other one-time payments.
* '''One-time payments''' (''via'' '''[https://www.paypal.com/us/webapps/mpp/home Paypal]'''l) : punctual payments of 1, 3, 6 or 12 months, but also of 2, 3, 5 or 7 days, which can be cumulated with other one-time payments.
* '''One-time payments''' (''via'' '''[https://store.steampowered.com/app/373720/Ryzom/ Steam]''') : available only if the Ryzom account is linked to a Steam account. In this case, the payment options listed above are not accessible

Both Xsolla and Steam accept a wide variety of payment methods.

== The recurring subscription via Xsolla ==

[[File:New Billing image2.png|center|512px]]
{|
|-
| 
::#[[#How to activate the recurring subscription?|How to activate the recurring subscription?]]
::#[[#How to switch from a one-time payment via Paypal to a recurring subscription?|How to switch from a one-time payment via Paypal to a recurring subscription?]]
::#[[#How to activate a recurring subscription if the Ryzom account is linked to a Steam account?|How to activate a recurring subscription if the Ryzom account is linked to a Steam account?]]
::#[[#How to unsubscribe?|How to unsubscribe?]]
::#[[#How to change the periodicity of the recurring subscription?|How to change the periodicity of the recurring subscription?]]
::#[[#What happens to the bank details entered when subscribing to a recurring Premium subscription?|What happens to the bank details entered when subscribing to a recurring Premium subscription?]]
::#[[#Who to contact in case of a billing problem?|Who to contact in case of a billing problem?]]
|}

=== How to activate the recurring subscription? ===

<div style="margin-left:1.251cm;margin-right:0cm;">Choose the first subscription option ('''''Recurring Payments''''') and enter the requested information.</div>

=== How to switch from a one-time payment via Paypal to a recurring subscription? ===

<div style="margin-left:1.251cm;margin-right:0cm;">Choose the first subscription option ('''''Recurring Payments''''') and enter the requested information.</div>

<div style="color:#000000;margin-left:1.251cm;margin-right:0cm;">Please note that the recurring subscription ''via'' Xsolla starts on the same day as the subscription, but that the next payment is delayed of the number of Premium days you have left. So you don't lose any Premium days paid ''via'' Paypal.</div>

=== How to activate a recurring subscription if the Ryzom account is linked to a Steam account? ===

<div style="margin-left:1.251cm;margin-right:0cm;">Payments via Steam being one-time ones, not recurring ones, this is not possible without further intervention. Here is the procedure to follow:</div>
# Untie your account from Steam using the link at the bottom of the billing window (see screenshot below).
# Choose the first subscription option ('''''Recurring Payments''''') and enter the requested information.
# Link again (optionally) your account to Steam on the next game launch.

<div style="color:#000000;margin-left:1.251cm;margin-right:0cm;">Please note that the recurring subscription ''via'' Xsolla starts on the same day as the subscription, but that the next payment is delayed of the number of Premium days you have left. So you don't lose any Premium days paid ''via'' Steam.</div>

=== How to unsubscribe? ===

<div style="margin-left:1.251cm;margin-right:0cm;">Click on the '''''Cancel your subscription''''' button. An email containing a link to cancel the subscription will then be sent to you.</div>

<div style="margin-left:1.251cm;margin-right:0cm;">Your Premium access is retained until the date on which the next payment should have occured.</div>

=== How to change the periodicity of the recurring subscription? ===

# Click on the '''''Cancel your subscription''''' button. An email containing a link to cancel the subscription will then be sent to you.
# Select '''''Recurring Payments''''' and then choose the desired new duration.

=== What happens to the bank details entered when subscribing to a recurring Premium subscription? ===

<div style="margin-left:1.251cm;margin-right:0cm;">The subscription system is entirely managed by XSolla, sole recipient of this information. The Ryzom team has no access to it.</div>

=== Who to contact in case of a billing problem? ===

<div style="margin-left:1.251cm;margin-right:0cm;">In case of a problem with the billing system, please contact exclusively Xsolla support by clicking on the '''''Xsolla Customer Support''''' link at the bottom of the transaction window. Indeed, the Ryzom team does not manage the payment process.</div>

== One-time payments ==

[[File:New Billing image3.png|center|512px]]

=== One-time payments via Xsolla and Paypal ===
{|
|-
| 
::#[[#How to activate the one-time payment via Xsolla or Paypal?|How to activate the one-time payment via Xsolla or Paypal?]]
::#[[#How to activate a one-time payment via Xsolla or Paypal if the Ryzom account is linked to a Steam account?|How to activate a one-time payment via Xsolla or Paypal if the Ryzom account is linked to a Steam account?]]
::#[[#Can one-time payments be accumulated?|Can one-time payments be accumulated?]]
::#[[#What happens to the bank details entered when activating a one-time payment?|What happens to the bank details entered when activating a one-time payment?]]
::#[[#Who to contact in case of a billing problem?|Who to contact in case of a billing problem?]]
|}

==== How to activate the one-time payment via Xsolla or Paypal? ====

<div style="margin-left:1.251cm;margin-right:0cm;">Choose the desired Premium duration (two days, three days, five days or one week) and follow the instruction</div>

==== How to activate a one-time payment via Xsolla or Paypal if the Ryzom account is linked to a Steam account? ====

<div style="margin-left:1.251cm;margin-right:0cm;">To benefit of these payment options, the Ryzom account has first to be untied from the Steam account. These options will then be visible and selectable from the billing account. This will only result in the Ryzom account having to be linked again to the Steam account on the next game launch.</div>

==== Can one-time payments be accumulated? ====

<div style="margin-left:1.251cm;margin-right:0cm;">Yes, and this makes it possible to accumulate one-time payments of several days or months in order to extend the total duration of your Premium access.</div>

<div style="margin-left:1.251cm;margin-right:0cm;">To do this, click on '''''Add Premium Days''''' and then select the desired duration.</div>

<div style="margin-left:1.251cm;margin-right:0cm;">Note that it is possible to cumulate the single payments ''via'' Xsolla and those ''via'' Paypal.</div>

==== What happens to the bank details entered when activating a one-time payment? ====

<div style="margin-left:1.251cm;margin-right:0cm;">The subscription system is entirely managed by XSolla and by Paypal, sole recipients of this information. The Ryzom team has no access to it.</div>

==== Who to contact in case of a billing problem? ====

<div style="margin-left:1.251cm;margin-right:0cm;">In case of a problem with the billing system, please contact exclusively Xsolla support or that of Paypal. Indeed, the Ryzom team does not manage the payment process.</div><div style="margin-left:1.251cm;margin-right:0cm;">For Xsolla, click on the '''''Xsolla Customer Support''''' link at the bottom of the transaction window.</div><div style="margin-left:1.251cm;margin-right:0cm;">For Paypal, click on the '''''Contact''''' link at the bottom of the transaction window.</div>

=== One-time payments via Steam ===

[[File:New Billing image4.png|center|512px]]
{|
|-
| 
::#[[#How to activate the one-time payment via Steam?|How to activate the one-time payment via Steam?]]
::#[[#What happens to the bank details entered when activating a one-time payment?|What happens to the bank details entered when activating a one-time payment?]]
::#[[#Who to contact in case of a billing problem?|Who to contact in case of a billing problem?]]
::#[[#Worldpay case|Who to contact in case of a billing problem?]]
|}

==== How to activate the one-time payment via Steam? ====

<div style="margin-left:1.251cm;margin-right:0cm;">If the Ryzom account is linked to a Steam account, only the payment option ''via'' Steam is visible on the Ryzom billing system. Just click on it and follow the instructions.</div>

<div style="margin-left:1.251cm;margin-right:0cm;">'''Special case''': if a recurring subscription ''via'' Xsolla has been taken out before linking the Ryzom account to the Steam account, the Steam option is not available on the Ryzom billing system. To make it available, the recurring subscription must be cancelled first.</div>

==== What happens to the bank details entered when activating a one-time payment? ====

<div style="color:#000000;margin-left:1.251cm;margin-right:0cm;">The subscription system is entirely managed by Valve, sole recipient of this information. The Ryzom team has no access to it.</div>

==== Who to contact in case of a billing problem? ====

<div style="margin-left:1.251cm;margin-right:0cm;">The Steam payment system is managed by Valve. In case of problem with the billing system, contact Steam Support. Indeed, the Ryzom team does not manage the payment process.</div>

== Worldpay case ==

<div style="margin-left:1.251cm;margin-right:0cm;">Ryzom's previous billing system allowed a recurring subscription to be taken out only ''via'' WorldPay. This option will remain operational for a few months during the transition period.</div>

<div style="margin-left:1.251cm;margin-right:0cm;">Please note that the switch from recurring subscription ''via'' WorldPay to recurring subscription ''via'' Xsolla is not automatic: it has to be done manually by the concerned players. The Premium access time remaining on the Worldpay subscription is then automatically carried over to the Xsolla subscription.</div>

<noinclude>
----
<references/>
<subpages/>
----
{{portal|Forge|Gameplay}}
[[Category:Forge]] [[Category:Ryzom Team]] [[Category:Game updates 2020]]
[[de:Neuer Abrechnungsservice]] [[es:Nuevo servicio de facturación]] [[en:New Billing Service]] [[fr:Nouveau service de facturation]] [[ru:Новая биллинговая услуга]]{{last version link|New Billing Service}}</noinclude>

New Billing Service

2020-08-26T21:19:44Z

Moniq: /* Payment Options */ "ou" -> "or"

<noinclude>{{Trad
|DE=Neuer Abrechnungsservice
|ES=Nuevo servicio de facturación
|EN=New Billing Service
|FR=Nouveau service de facturation
|RU=Новая биллинговая услуга
}}</noinclude>

[[file:Ryzom logo.png|center]]

<center><big><big><big>'''New billing system'''</big></big></big></center>

Ryzom is getting a new billing system offering more possibilities in terms of subscription duration and means of payment. The system accessible from its website [https://www.ryzom.com/ https://www.ryzom.com].

= Durations of subscription and rates =

=== Premium Rates ===

{| style="border-spacing:0;margin:auto;width:17cm;"
|-
| align=center style="background-color:transparent;border-top:0.5pt solid #000000;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:none;padding:0.097cm;color:#000000;" | '''Xsolla''''' (lower rates for 12 months) *''
| align=center style="background-color:transparent;border-top:0.5pt solid #000000;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:none;padding:0.097cm;color:#000000;" | '''Paypal'' '''(tariffs 3, 6 and 12 months down)''
| align=center style="background-color:transparent;border:0.5pt solid #000000;padding:0.097cm;color:#000000;" | '''Steam '''''(unchanged rates)''
|-
| style="background-color:transparent;border-top:none;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:none;padding:0.097cm;" | 1 month: 7.95€

3 months: 22.50€

6 months: 41.70€

<div style="color:#000000;">12 months: 59.00€</div>
| style="background-color:transparent;border-top:none;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:none;padding:0.097cm;" | 1 month: 8.95€

3 months: 22.50€

6 months: 41.70€

<div style="color:#000000;">12 months: 59.00€</div>
| style="background-color:transparent;border-top:none;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:0.5pt solid #000000;padding:0.097cm;" | 1 month: 9.98€

3 months: 27.98€

6 months: 52.95€

<div style="color:#000000;">12 months: 96.95€</div>
|-
|}

<div style="color:#000000;"><nowiki>* </nowiki>Please note, however, that some new payment methods offered by Xsolla cause an additional cost, as it is already the case for Paypal and Steam.</div>

=== Short duration Premium rates ===

The Premium rates for short periods are being introduced.

{| style="border-spacing:0;margin:auto;width:17cm;"
|-
| align=center style="background-color:transparent;border-top:0.5pt solid #000000;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:none;padding:0.097cm;color:#000000;" | '''Xsolla'''
| align=center style="background-color:transparent;border:0.5pt solid #000000;padding:0.097cm;color:#000000;" | '''Paypal'''
|-
| style="background-color:transparent;border-top:none;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:none;padding:0.097cm;" | 2 days: 1.5€

3 days: 2€

5 days: 2.5€

<div style="color:#000000;">7 days: 3€</div>
| style="background-color:transparent;border-top:none;border-bottom:0.5pt solid #000000;border-left:0.5pt solid #000000;border-right:0.5pt solid #000000;padding:0.097cm;" | 2 days: 2€

3 days: 2.5€

5 days: 3€

<div style="color:#000000;">7 days: 3.5€</div>

|-
|}
= Premium advantages =

<div style="text-align:center;">[[File:New Billing image5.png|center|512px]]</div>

= Payment Options =

[[File:New Billing image1.png|center|512px]]

The Premium access offers several payment options: * '''Recurring payments''' (via '''[https://xsolla.com/ Xsolla]'''), with automatic renewal each 1, 3, 6 or 12 months.
* '''One-time payments '''(''via'' '''[https://xsolla.com/ Xsolla]''') : punctual payments of 1, 3, 6 or 12 months, which can be cumulated with other one-time payments.
* '''Short duration one-time payments''' (''via'' '''[https://xsolla.com/ Xsolla]''') : punctual payments of 1, 2, 5 or 7 days, which can be cumulated with other one-time payments.
* '''One-time payments''' (''via'' '''[https://www.paypal.com/us/webapps/mpp/home Paypal]'''l) : punctual payments of 1, 3, 6 or 12 months, but also of 2, 3, 5 or 7 days, which can be cumulated with other one-time payments.
* '''One-time payments''' (''via'' '''[https://store.steampowered.com/app/373720/Ryzom/ Steam]''') : available only if the Ryzom account is linked to a Steam account. In this case, the payment options listed above are not accessible

Both Xsolla and Steam accept a wide variety of payment methods.

== The recurring subscription via Xsolla ==

[[File:New Billing image2.png|center|512px]]
{|
|-
| 
::#[[#How to activate the recurring subscription?|How to activate the recurring subscription?]]
::#[[#How to switch from a one-time payment via Paypal to a recurring subscription?|How to switch from a one-time payment via Paypal to a recurring subscription?]]
::#[[#How to activate a recurring subscription if the Ryzom account is linked to a Steam account?|How to activate a recurring subscription if the Ryzom account is linked to a Steam account?]]
::#[[#How to unsubscribe?|How to unsubscribe?]]
::#[[#How to change the periodicity of the recurring subscription?|How to change the periodicity of the recurring subscription?]]
::#[[#What happens to the bank details entered when subscribing to a recurring Premium subscription?|What happens to the bank details entered when subscribing to a recurring Premium subscription?]]
::#[[#Who to contact in case of a billing problem?|Who to contact in case of a billing problem?]]
|}

=== How to activate the recurring subscription? ===

<div style="margin-left:1.251cm;margin-right:0cm;">Choose the first subscription option ('''''Recurring Payments''''') and enter the requested information.</div>

=== How to switch from a one-time payment via Paypal to a recurring subscription? ===

<div style="margin-left:1.251cm;margin-right:0cm;">Choose the first subscription option ('''''Recurring Payments''''') and enter the requested information.</div>

<div style="color:#000000;margin-left:1.251cm;margin-right:0cm;">Please note that the recurring subscription ''via'' Xsolla starts on the same day as the subscription, but that the next payment is delayed of the number of Premium days you have left. So you don't lose any Premium days paid ''via'' Paypal.</div>

=== How to activate a recurring subscription if the Ryzom account is linked to a Steam account? ===

<div style="margin-left:1.251cm;margin-right:0cm;">Payments via Steam being one-time ones, not recurring ones, this is not possible without further intervention. Here is the procedure to follow:</div>
# Untie your account from Steam using the link at the bottom of the billing window (see screenshot below).
# Choose the first subscription option ('''''Recurring Payments''''') and enter the requested information.
# Link again (optionally) your account to Steam on the next game launch.

<div style="color:#000000;margin-left:1.251cm;margin-right:0cm;">Please note that the recurring subscription ''via'' Xsolla starts on the same day as the subscription, but that the next payment is delayed of the number of Premium days you have left. So you don't lose any Premium days paid ''via'' Steam.</div>

=== How to unsubscribe? ===

<div style="margin-left:1.251cm;margin-right:0cm;">Click on the '''''Cancel your subscription''''' button. An email containing a link to cancel the subscription will then be sent to you.</div>

<div style="margin-left:1.251cm;margin-right:0cm;">Your Premium access is retained until the date on which the next payment should have occured.</div>

=== How to change the periodicity of the recurring subscription? ===

# Click on the '''''Cancel your subscription''''' button. An email containing a link to cancel the subscription will then be sent to you.
# Select '''''Recurring Payments''''' and then choose the desired new duration.

=== What happens to the bank details entered when subscribing to a recurring Premium subscription? ===

<div style="margin-left:1.251cm;margin-right:0cm;">The subscription system is entirely managed by XSolla, sole recipient of this information. The Ryzom team has no access to it.</div>

=== Who to contact in case of a billing problem? ===

<div style="margin-left:1.251cm;margin-right:0cm;">In case of a problem with the billing system, please contact exclusively Xsolla support by clicking on the '''''Xsolla Customer Support''''' link at the bottom of the transaction window. Indeed, the Ryzom team does not manage the payment process.</div>

== One-time payments ==

[[File:New Billing image3.png|center|512px]]

=== One-time payments via Xsolla and Paypal ===
{|
|-
| 
::#[[#How to activate the one-time payment via Xsolla or Paypal?|How to activate the one-time payment via Xsolla or Paypal?]]
::#[[#How to activate a one-time payment via Xsolla or Paypal if the Ryzom account is linked to a Steam account?|How to activate a one-time payment via Xsolla or Paypal if the Ryzom account is linked to a Steam account?]]
::#[[#Can one-time payments be accumulated?|Can one-time payments be accumulated?]]
::#[[#What happens to the bank details entered when activating a one-time payment?|What happens to the bank details entered when activating a one-time payment?]]
::#[[#Who to contact in case of a billing problem?|Who to contact in case of a billing problem?]]
|}

==== How to activate the one-time payment via Xsolla or Paypal? ====

<div style="margin-left:1.251cm;margin-right:0cm;">Choose the desired Premium duration (two days, three days, five days or one week) and follow the instruction</div>

==== How to activate a one-time payment via Xsolla or Paypal if the Ryzom account is linked to a Steam account? ====

<div style="margin-left:1.251cm;margin-right:0cm;">To benefit of these payment options, the Ryzom account has first to be untied from the Steam account. These options will then be visible and selectable from the billing account. This will only result in the Ryzom account having to be linked again to the Steam account on the next game launch.</div>

==== Can one-time payments be accumulated? ====

<div style="margin-left:1.251cm;margin-right:0cm;">Yes, and this makes it possible to accumulate one-time payments of several days or months in order to extend the total duration of your Premium access.</div>

<div style="margin-left:1.251cm;margin-right:0cm;">To do this, click on '''''Add Premium Days''''' and then select the desired duration.</div>

<div style="margin-left:1.251cm;margin-right:0cm;">Note that it is possible to cumulate the single payments ''via'' Xsolla and those ''via'' Paypal.</div>

==== What happens to the bank details entered when activating a one-time payment? ====

<div style="margin-left:1.251cm;margin-right:0cm;">The subscription system is entirely managed by XSolla and by Paypal, sole recipients of this information. The Ryzom team has no access to it.</div>

==== Who to contact in case of a billing problem? ====

<div style="margin-left:1.251cm;margin-right:0cm;">In case of a problem with the billing system, please contact exclusively Xsolla support or that of Paypal. Indeed, the Ryzom team does not manage the payment process.</div><div style="margin-left:1.251cm;margin-right:0cm;">For Xsolla, click on the '''''Xsolla Customer Support''''' link at the bottom of the transaction window.</div><div style="margin-left:0cm;margin-right:0cm;">For Paypal, click on the '''''Contact''''' link at the bottom of the transaction window.</div>

=== One-time payments via Steam ===

[[File:New Billing image4.png|center|512px]]
{|
|-
| 
::#[[#How to activate the one-time payment via Steam?|How to activate the one-time payment via Steam?]]
::#[[#What happens to the bank details entered when activating a one-time payment?|What happens to the bank details entered when activating a one-time payment?]]
::#[[#Who to contact in case of a billing problem?|Who to contact in case of a billing problem?]]
::#[[#Worldpay case|Who to contact in case of a billing problem?]]
|}

==== How to activate the one-time payment via Steam? ====

<div style="margin-left:1.251cm;margin-right:0cm;">If the Ryzom account is linked to a Steam account, only the payment option ''via'' Steam is visible on the Ryzom billing system. Just click on it and follow the instructions.</div>

<div style="margin-left:1.251cm;margin-right:0cm;">'''Special case''': if a recurring subscription ''via'' Xsolla has been taken out before linking the Ryzom account to the Steam account, the Steam option is not available on the Ryzom billing system. To make it available, the recurring subscription must be cancelled first.</div>

==== What happens to the bank details entered when activating a one-time payment? ====

<div style="color:#000000;margin-left:1.251cm;margin-right:0cm;">The subscription system is entirely managed by Valve, sole recipient of this information. The Ryzom team has no access to it.</div>

==== Who to contact in case of a billing problem? ====

<div style="margin-left:1.251cm;margin-right:0cm;">The Steam payment system is managed by Valve. In case of problem with the billing system, contact Steam Support. Indeed, the Ryzom team does not manage the payment process.</div>

== Worldpay case ==

<div style="margin-left:1.251cm;margin-right:0cm;">Ryzom's previous billing system allowed a recurring subscription to be taken out only ''via'' WorldPay. This option will remain operational for a few months during the transition period.</div>

<div style="margin-left:1.251cm;margin-right:0cm;">Please note that the switch from recurring subscription ''via'' WorldPay to recurring subscription ''via'' Xsolla is not automatic: it has to be done manually by the concerned players. The Premium access time remaining on the Worldpay subscription is then automatically carried over to the Xsolla subscription.</div>

<noinclude>
----
<references/>
<subpages/>
----
{{portal|Forge|Gameplay}}
[[Category:Forge]] [[Category:Ryzom Team]] [[Category:Game updates 2020]]
[[de:Neuer Abrechnungsservice]] [[es:Nuevo servicio de facturación]] [[en:New Billing Service]] [[fr:Nouveau service de facturation]] [[ru:Новая биллинговая услуга]]{{last version link|New Billing Service}}</noinclude>

Special command

2020-07-17T20:06:35Z

Moniq: +/setuiscale command

<noinclude>{{Trad
|DE = Chatbefehle |DEs= 3
|EN = Special command |ENs= 0
|ES = Comandos especiales |ESs= 1
|FR = Commandes spéciales |FRs= 0
|RU = Специальные команды |RUs= 1
|H =
|palette=
|ref=
|com=
}}</noinclude>
See [[Chat]] and [[Chat/RC FAQ|RC FAQ]] about the external Ryzom Rocket Chat.
==Emotes==

See the [[Emote]] page.

==Player information==
*'''/time''' ''Displays your current local time and UTC time in the around chat.''
*'''/version''' ''Displayes your Ryzom client version.''
*'''/where''' ''Displays your current location as a floating message at the top of the screen as well as in System Info.''
*'''/who''' ''Displays the names of all the players in a region, sorted by account age. List is displayed in System Info.''
*'''/who gm''' ''Displays all the CSR and GM presently online. Note that CSR and GM have a special flag they can activate to hide their online presence, even from this command. List is displayed in System Info.''

== Online Status ==
This Function is to set the Output in your Friends or Guildmember Chat if you are come ON- /Offline.
*'''/a showOnline 1''' Only Friends and Guildmembers can see that you are come ON- /Offline.
*'''/a showOnline 2''' Just Guildmembers can see that you come ON- /Offline.
*'''/a showOnline 0''' Everyone can see it. (Default)

==Guild Commands==
*'''/guildmotd <message>''' ''Updates the guild message of the day. Can only be used by officers, high officers and the guild leader.''
*'''/guildinvite <playername>''' ''Invites a player to your guild. Can only be used by officers, high officers and the guild leader'

==League Commands==
*'''/league <leaguename>''' ''Creates a league with the given name and brings your team into the league. Can only be used by team leader.''
*'''/leagueinvite <playername>''' ''Invites a player's team into your league. Invitation will go to the player's team's leader''
*'''/leaguequit''' ''Quits your league, quits your team from the league if you are team leader.
*'''/leaguekick <playername>''' ''Kick a person or team (if the person is team leader) out of your league''

==Miscellaneous==
*'''/afk <autoresponse>''' ''Activates the afk tag so that other players can see you are away from your terminal. The message is optional and is displayed when a player sends you a tell. This is just a visual indicator, and will not protect you from attacks by flora, fauna or other players.''
*'''/assist''' or '''/as''' ''Targets the target of the targeted entity.''
*'''/self''' ''Target yourself.''
*'''/brutalQuit''' ''Instantaneously quits the game client.''
*'''/chatLog''' ''Creates a chatlog in the save folder located in Ryzom's main directory.''
*'''/follow''' ''Follows the targeted entity.''
*'''/ignore <playername>''' ''Adds a player to your ignore list''
*'''/invite <playername>''' ''Invites a player to your team. Can only be used by the team leader or by someone who is not teamed.''
*'''/mount''' ''Mounts your mektoub mount. You must be near your mount and it must be outside of the stable.''
*'''/random <lowest_number> <highest_number>''' ''Draws a random number between the first and last provided. If only one number is provided, the other limit is set to 1. The result is displayed in the Around chat and visible to everyone else nearby. Limits for this draw: [-32767, 32767]''
*'''/sleep <number>''' ''Puts the game client to sleep for the specified amount of seconds. You cannot do anything in this time.''
*'''/tar <name>''' ''Finds the nearest entity whose name contains the given string. Use single or double quotes for exact matching (e.g. NPC with two names). If no quotes are used, /tar will look for all words in the string, and match any! See more info in the forums: [https://app.ryzom.com/app_forum/index.php?page=topic/view/29692/1&post195145=en#1 Patch 3.5.0 - 2019-05-18]''
* '''new:''' '''/lmtar <name>''' '' Add target closest landmark
*'''/target <name>''' ''Same as /tar''
*'''/tarq <name>''' ''Same as /tar, but it doesn't show the "entity not found" message in the sysinfo window''
*'''/target_quiet <name>''' ''Same as /tarq''
*'''/unmount''' ''Dismounts your mektoub mount.''
*'''/chat''' ''Keeps focus on chat, [Enter] doesn't quit chat''
*'''/go''' ''Opens the WebIG'' (= '''SHIFT+W''')
* [[File:BarreWebapp.png|thumb|right|Webapps main: Achievements, ... Support]]'''/appzone hide''' Hide the [[Webapps main|webapps]] toolbar

=== Some new commands ===
* [[Patch 00813|March 2020]]: New '''<nowiki>/showHideUserLandMark</nowiki>''' command to hide markers on map (more on the FAQ Map [[Use the map]]).

==Chat commands==
'''New''' (In Game only): right click on an older message copy it, then just paste (by CTRL+V).

===Around===
[[File:FR 2019-10-05 22-58-42 Avendale dialog.png|320px|right|A flag to show Deepl translated (here, from English to French)]]Messages sent normally in the around channel have a 25m range.
*'''/s'''
*'''/say'''

These commands will make your messages have a 50m range and will appear red (by default) for you.
*'''/sh'''
*'''/shout'''
*'''/y'''
*'''/yell'''

<div style="margin:0em; padding:1em 2em;border: thin inset #{{ColorAtys|type=dark|group=HRP}};background:#{{ColorAtys|type=light|group=HRP}};color:#{{ColorAtys|type=fg|group=HRP}};">
With [[Patch 2019|JA 2603 patch]] (in 2019/08), '''all text in Around is translated''' using [https://www.deepl.com/translator Deepl].

The image above is an example, a flag indicates that Deepl has translated (here from English to French) - excerpt from the album [[:atys:Category:Kami blast|Kami blast]].

* The sentences in surroundings channel prefixed by '''"<code>></code>"''' won't be translated.
* To disable translation :
*:/a setDontTranslateLangs separated by pipe character
*:Example: /a setDontTranslateLangs us|fr
More info on the forum: https://app.ryzom.com/app_forum/index.php?page=topic/view/30307/7
</div>

===Guild===
With these commands a message is sent to the guild channel, visible to all who are in the same guild as you.
*'''/g'''
*'''/gu'''
*'''/guild'''

===Region===
These commands send a message visible to all who are in the same region as you at the time.
*'''/r'''
*'''/re'''
*'''/region'''

===Team/Party===
With these commands a message is sent to the Team channel and is visible to those currently in your party.
*'''/p'''
*'''/party'''
*'''/te'''
*'''/team'''

===Universe channel===
These send a message to the universe channel, which is visible to everyone online at that moment.
*'''/u'''
*'''/universe'''

Missing English (or German...) uni ? '''/a connectLangChannel en'''

===Dynamic Channels===
A player can have up to 5 dynamic channels: One faction channel, one racial channel, two custom channels and possibly an event channel too.

However, it's also possible to have no dynamic channels at all. And usually players are prohibited from talking in event channels. So depending on which dynamic channels you have, these commands might not work.
*'''/0''' ''Talk in the player's 1st dynamic chat channel. The first dynamic channel is usually the faction channel.''
*'''/1''' ''Talk in the player's 2nd dynamic chat channel. The second dynamic channel is usually the racial channel.''
*'''/2''' ''Talk in the player's 3rd dynamic chat channel. Could be a custom channel or an event channel.''
*'''/3''' ''Talk in the player's 4th dynamic chat channel. Could be a custom channel or an event channel.''
*'''/4''' ''Talk in the player's 5th dynamic chat channel. You'll never have this many dynamic channels unless there's an event channel active.''

===Custom channels===
You can create your own channels as well, or join those created by others. A player can be connected to at most 2 custom channels at a time.
*'''/channel <channelname>''' ''Join the channel with the given name, or create it if doesn't exist already.''
*'''/channel <channelname> <password>''' ''Join or create a channel with password protection.''
*'''/channel <channelname> *''' ''Leave the channel with the given name.''

[[Chat/RC FAQ|RC FAQ]] can have custom channels too (as much more features - [[RC]] is for Ryzom Rocket Chat, the external chat).

===Private messages===
*'''/t <playername> <message>''' ''Send a whisper to a player''
*'''/tell <playername> <message>''' ''Send a whisper to a player''
*'''/tell <playername>(<server>) <message>''' ''Send a whisper to a player on another server.''

==Outfit Commands==
*'''/createGroup <OutfitGroupName> <true>''' ''creates a group of items, an outfit from the items the character currently wears, when "true" optional parameter is specified, empty slots are unequipped"
*'''/moveGroup <OutfitGroupName> <pet_animal1> or <player_room>''' ''moves the outfit to pet_animal1 or player_room''
*'''/equipGroup <OutfitGroupName>''' ''equips the item group''
*'''/deleteGroup <OutfitGroupName>''' ''deletes the item group''
*'''/naked''' ''to remove all equipments''
*'''/listGroup''' ''Lists all currently saved goups ''
'''
NOTES''':
* /equipGroup can be used from a [[Macros|MACRO]]
* /moveGroup can be used from a [[Macros|MACRO]], or by a right click on the item in inventory.
[https://app.ryzom.com/app_forum/index.php?page=topic/view/26843/1 For further reading on groups].


==Other commands==
*'''/setuiscale <ScaleFactor>''' ''Set user interface scale factor from 0.8 to 2.0''

==Developer and GM Commands==
Developers, GMs, [[CSR]] and the events team have special commands that they can use for debugging, support, and for hosting live events. You can read external [https://raw.githubusercontent.com/osgcc/ryzom/master/ryzom/server/data_shard/client_commands_privileges.txt list of required privileges for client commands] or [https://ryzomcore.atlassian.net/wiki/spaces/RC/pages/19365937/Shard+Commands Shard commands] list

==Obsolete Commands==
*'''/supportChat''' ''Opens the support channel tab.''
*'''/a summonPet <number>''' ''Summons one of your pets to your current location. See [[Game updates/20041208|Patch 27]].''
*'''/ah show inv_guild''' ''Shows guild inventory. Works outside guild hall. Can get or put dappers, but cannot take out or put in items.''
*'''/ah show_hide inv_guild to toggle''' ''Hides guild inventory.''
*'''/ah show inv_room''' ''Shows the inventory of your apartment. Works outside apartment. Cannot take out or put in items.
*'''/ah show_hide inv_room to toggle''' ''Hides the inventory of your apartment.''
*'''/flush''' ''Manually saves your character.''

==See also==
*[[Emote]]
* translation links: [[DeepL]]

<noinclude>
{{Portal|Gameplay}}
[[Category:Commands]][[Category:Starting Out]][[Category:Glossary|Commands]]
</noinclude>