<div><div>I want to respond to your comments:</div><div><br /><em>>I haven't got a dochub account, so I cannot comment in-line</em></div><div>Translated my document from Latex into google docs. New link <span style="color:#444444;font-family:roboto,helvetica,arial,sans-serif;font-size:13px;white-space:normal;"><a href="https://goo.gl/Dmu6Qx">https://goo.gl/Dmu6Qx</a></span></div><div> </div><div><font color="#444444" face="roboto, helvetica, arial, sans-serif"><span style="font-size:13px;white-space:normal;">></span></font><em>You never mention privacy anywhere</em><br />Yes, this is really important. Wrote that all data will be collected anonymously and only with the consent of the user.</div><div> </div><div>><em>We already have a number of technologies that are somewhat related, like<br />the action recording, but none are available for for all tools, dialogs and<br />actions. It would be good to setup a generic system that can collect user<br />actions</em></div><div>I think this will require fixing the recording actions system. This is a nontrivial task that requires a lot of time. I will make api to the own action tracking system, which in the future can be completed.</div><div> </div><div>><em>Performance: how are you going to avoid a performance hit when writing out<br />data?</em></div><div>I will store the data of the current session using the probuf-generated structures in the RAM. It should be fast. If this data starts to take up too many memory, I will write them to a file. Writing to a file is not very fast, but on a general performance of Krita this should not affect.</div><div><br />><em>On the server-side, your proposal analyzes an entire session's logfile<br />in one go -- did I understand that correctly? Could the proposal be expanded<br />by sending a crash log on restart as well?</em></div><div>On the server side, we analyze the file that was sent there. It may not always be a single session file, it can be a file of several sessions.</div><div>I think that we could collect the data from kis_asserts. Collecting data about crashes can be problematic. We can use Dmitry's suggestion to collect the number of successful launches and unsuccessful program completions.</div><div> </div><div><div><em>>For the Steam part of the project, I guess we could limit the scope </em></div><div><em>to user-visible achievements only. </em></div><div>I think that it is not very difficult and the field of obtaining achievements depends only on imagination. I added a couple of examples of achivok. The main idea - for us everything does Steam SDK. You can read more about the achievements of <a href="https://partner.steamgames.com/documentation/ugs">https://partner.steamgames.com/documentation/ugs</a> (you need registration in the Steam).</div><div> </div></div><div><em>></em><em>It would be good to have an </em><div><em>example of how one particular type of log (e.g. tool activation metric) </em></div><div><em>goes through all the stages, from Krita to web frontend with analytics </em></div><div><em>view. </em></div><div><div>I described how the data will "move" on the client side(I have updated description). Nginx proxy the data on the backend-server. The backend server writes data to the database. I would like to make a backend-server using the Wt (c ++) library, but this is a discussion issue. Clickhouse is column-oriented database.</div><div>Several tables will be created based on the table from item 3.1. We will be able to implement analytics on the basis of the already available columns. This is what the creators of this database recommend. More details about Clickhouse can be read here https://clickhouse.yandex/reference_en.html</div><div>(in English) or here https://habrahabr.ru/company/yandex/blog/303282/ (in Russian).</div></div><div> </div></div></div><div>27.03.2017, 14:46, "Boudewijn Rempt" <<span>boud@valdyas.org</span>>:</div><blockquote type="cite"><p>Hi Alexey,<br /><br />I haven't got a dochub account, so I cannot comment in-line. Here are some notes:<br /><br /> * You never mention privacy anywhere: any proposal that is about collecting<br />usage data needs a very clear mention of the collection being opt-in and the<br />data being anonymized.<br /> * The client-side implementation is reasonably clear, but I miss an overview<br />of which data is going to be collected exactly.<br /> * We already have a number of technologies that are somewhat related, like<br />the action recording, but none are available for for all tools, dialogs and<br />actions. It would be good to setup a generic system that can collect user<br />actions<br /> * Performance: how are you going to avoid a performance hit when writing out<br />data?<br /> * On the server-side, your proposal analyzes an entire session's logfile<br />in one go -- did I understand that correctly? Could the proposal be expanded<br />by sending a crash log on restart as well?<br /><br />For the rest, nice and solid proposal with all the relevant information<br />available: it's only because it's so clear that I was able to ask a bunch<br />of questions :-)<br /><br /><br />On Mon, 27 Mar 2017, Kapustin Alexey wrote:<br /> </p><blockquote> Hi all!<br /> I would like to listen to comments and suggestions about my proposal "Telemetry for getting statistics for<br /> which features are used the most in Krita": <a href="https://goo.gl/uzhELn">https://goo.gl/uzhELn</a><br /> I would really appreciate for feedback.<br /> Cheers, Alexey.<br /><br /> </blockquote><p> </p><span>--<br />Boudewijn Rempt | <a href="http://www.krita.org/">http://www.krita.org</a>, <a href="http://www.valdyas.org/">http://www.valdyas.org</a></span></blockquote>