[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-kimageshop
Subject: Re: Need Feedback on GSOC Proposal
From: Dmitry Kazakov <dimula73 () gmail ! com>
Date: 2017-03-30 11:23:39
Message-ID: f69ab86f-1d05-86d9-2bc4-295267dff74b () gmail ! com
[Download RAW message or body]
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@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
[Attachment #3 (text/html)]
<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body>
Hi, Alexey!<br>
<br>
I think you proposal is almost perfect now! :) Please submit it to
Google's application form.<br>
<br>
In the meantime we can start discussion among painters about which
properties of presets should be logged and which not.<br>
<br>
Timothee and David! Could you you help us with it?<br>
<br>
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?<br>
<br>
<br>
<br>
<div class="moz-cite-prefix">On 28.03.2017 22:25, Kapustin Alexey
wrote:<br>
</div>
<blockquote cite="mid:979011490729106@web16o.yandex.ru" type="cite">
<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
moz-do-not-send="true" \
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 moz-do-not-send="true"
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
<a class="moz-txt-link-freetext" \
href="https://clickhouse.yandex/reference_en.html">https://clickhouse.yandex/reference_en.html</a></div>
<div>(in English) or here
<a class="moz-txt-link-freetext" \
href="https://habrahabr.ru/company/yandex/blog/303282/">https://habrahabr.ru/company/yandex/blog/303282/</a> \
(in Russian).</div>
</div>
<div> </div>
</div>
</div>
<div>27.03.2017, 14:46, "Boudewijn Rempt" <<span><a \
class="moz-txt-link-abbreviated" \
href="mailto:boud@valdyas.org">boud@valdyas.org</a></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
moz-do-not-send="true" \
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 moz-do-not-send="true"
href="http://www.krita.org/">http://www.krita.org</a>, <a
moz-do-not-send="true" \
href="http://www.valdyas.org/">http://www.valdyas.org</a></span></blockquote> \
</blockquote> <br>
<pre class="moz-signature" cols="72">--
Dmitry Kazakov</pre>
</body>
</html>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic