Need Feedback on GSOC Proposal

[Dmitry Kazakov]

Hi, Alexey!

I think you proposal is almost perfect now! :) Please submit it to 
Google's application form.

In the meantime we can start discussion among painters about which 
properties of presets should be logged and which not.

Timothee and David! Could you you help us with it?

As far as I can guess, we cannot upload user-defined presets to our 
servers (they are private property). But we are interested in some 
properties, like size, presence of texture and so on. What properties 
you are interested it? Would you like to know, which of your presets are 
the most popular?



On 28.03.2017 22:25, Kapustin Alexey wrote:
> I want to respond to your comments:
>
> />I haven't got a dochub account, so I cannot comment in-line/
> Translated my document from Latex into google docs. New link 
> https://goo.gl/Dmu6Qx
> >/You never mention privacy anywhere/
> Yes, this is really important. Wrote that all data will be collected 
> anonymously and only with the consent of the user.
> >/We already have a number of technologies that are somewhat related, like
> the action recording, but none are available for for all tools, 
> dialogs and
> actions. It would be good to setup a generic system that can collect user
> actions/
> 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.
> >/Performance: how are you going to avoid a performance hit when 
> writing out
> data?/
> 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.
>
> >/On the server-side, your proposal analyzes an entire session's logfile
> in one go -- did I understand that correctly? Could the proposal be 
> expanded
> by sending a crash log on restart as well?/
> 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.
> 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.
> />For the Steam part of the project, I guess we could limit the scope /
> /to user-visible achievements only. /
> 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 
> https://partner.steamgames.com/documentation/ugs (you need 
> registration in the Steam).
> />//It would be good to have an /
> /example of how one particular type of log (e.g. tool activation metric) /
> /goes through all the stages, from Krita to web frontend with analytics /
> /view. /
> 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.
> 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
> (in English) or here https://habrahabr.ru/company/yandex/blog/303282/ 
> (in Russian).
> 27.03.2017, 14:46, "Boudewijn Rempt" <boud at valdyas.org>:
>>
>> Hi Alexey,
>>
>> I haven't got a dochub account, so I cannot comment in-line. Here are 
>> some notes:
>>
>>  * You never mention privacy anywhere: any proposal that is about 
>> collecting
>> usage data needs a very clear mention of the collection being opt-in 
>> and the
>> data being anonymized.
>>  * The client-side implementation is reasonably clear, but I miss an 
>> overview
>> of which data is going to be collected exactly.
>>  * We already have a number of technologies that are somewhat 
>> related, like
>> the action recording, but none are available for for all tools, 
>> dialogs and
>> actions. It would be good to setup a generic system that can collect user
>> actions
>>  * Performance: how are you going to avoid a performance hit when 
>> writing out
>> data?
>>  * On the server-side, your proposal analyzes an entire session's logfile
>> in one go -- did I understand that correctly? Could the proposal be 
>> expanded
>> by sending a crash log on restart as well?
>>
>> For the rest, nice and solid proposal with all the relevant information
>> available: it's only because it's so clear that I was able to ask a bunch
>> of questions :-)
>>
>>
>> On Mon, 27 Mar 2017, Kapustin Alexey wrote:
>>
>>      Hi all!
>>      I would like to listen to comments and suggestions about my
>>     proposal "Telemetry for getting statistics for
>>      which features are used the most in Krita": https://goo.gl/uzhELn
>>      I would really appreciate for feedback.
>>      Cheers, Alexey.
>>
>> --
>> Boudewijn Rempt | http://www.krita.org <http://www.krita.org/>, 
>> http://www.valdyas.org <http://www.valdyas.org/>

-- 
Dmitry Kazakov

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20170330/eb3e05e7/attachment.html>