<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
<p>Hi Regis, some good ideas in here, I'll comment inline<br>
</p>
<div class="moz-cite-prefix">On 28/8/19 12:00 am, Régis Haubourg
wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CABgOYCc3LXK5XCd-hmqSsSMNNw8hULM1kOuMNy-5RvpCxF52Sg@mail.gmail.com">
<div dir="ltr">Hi Cameron,<br>
</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Le mar. 27 août 2019 à 14:42,
Cameron Shorter <<a href="mailto:cameron.shorter@gmail.com"
moz-do-not-send="true">cameron.shorter@gmail.com</a>> a
écrit :<br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Andreas, Matteo, Anita, Rosa, Régis,</p>
<p>Some great and tough questions and suggestions here.</p>
<p>I'm won't have the bandwidth this week to answer all
questions to the depth I'd like, but I'll touch on a few
highlights.</p>
<p>I think we should start with clearly defining a vision
for what we would like QGIS docs to look like. Without
that, it is hard to do a gap analysis and quantify what is
missing. If people can't easily see the problem, they are
less likely to volunteer to fix it.</p>
</div>
</blockquote>
<div>To me, the final and ideal goal would be :</div>
<div>- each released version should be associated with an
english version within 2 months after the release</div>
<div>- Each LTR version should have fully translated version
when it is tagged as LTR</div>
<div>- New features should be easy to document and not be a
technical debt from developpers to documentation team. <br>
</div>
<div>- Training material should be updated for LTR, and tested,
within 6 months after the LTR release. I don't think being
faster is any useful given the delay in actual migrations and
large scale trainings</div>
<div>- Fixing an error in doc or translation should be doable
only with web interface and quickly, so that trainers can fix
issues during their training sessions. <br>
</div>
</div>
</blockquote>
This is a good start on a vision. <br>
<blockquote type="cite"
cite="mid:CABgOYCc3LXK5XCd-hmqSsSMNNw8hULM1kOuMNy-5RvpCxF52Sg@mail.gmail.com">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>This vision should cover the doc set we will create, the
level of quality we expect, the target audience who will
be satisfied, and how they will be satisfied, the
maintenance and currency and probably a few other things.</p>
<p>I think we should clearly and very publicly define what
we consider to be highly valuable contributions (like
working on core docs) vs disconnected docs which are only
available for a select few. Maybe this could be embedded
into a "doc pledge" which we can invite organisations to
sign up to. This will help sponsors to recognise,
prioritise and fund high quality initiatives.</p>
</div>
</blockquote>
<div>I think this was one the goals of the certification
program. Shortly said, you want to deliver certificates and be
yourself a certifying organisation. You need to be a regular
contributor, and thus a member of the community. There are
many ways to contribute of course, not only documentation. <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>I think QGIS docs would benefit hugely from someone
directly dedicated to a "community builder" type role. You
will typically see at least one and sometimes a few of
these people at the center of successful open source
projects. They typically go beyond the call of duty to
help all sorts of people work through all sorts of
challenges. They do whatever dirty work is required, such
as triaging issues and building releases, but also reach
out to people, invite them to help out, follow up with
them later, simplify and fix processes and so on. Note,
the primary focus of this role is empowering others to be
productive, and attracting others and being nice,
empathetic and encouraging. It is also about saying "no,
we don't have bandwidth to do that for you". I see
elements of this within the QGIS docs list, but I've the
feeling that QGIS has become too big for this to be
sustained on volunteer labour alone. It would be great if
this could be funded as a full time role. I'd suggest that
a community builder's role be modeled on some great
research into attracting and sustaining volunteers, which
I've summarised here:
<a
class="gmail-m_-8963796712721259496moz-txt-link-freetext"
href="http://cameronshorter.blogspot.com/2018/12/catching-elusive-episodic-volunteer.html"
target="_blank" moz-do-not-send="true">http://cameronshorter.blogspot.com/2018/12/catching-elusive-episodic-volunteer.html</a>
<br>
</p>
</div>
</blockquote>
<div>Much agreed. This leads us to progressively secure those
that contribute so much by paying them for this. The more
ressources we have, the more we'll be able to fund those low
level tasks (don't forget communication, code review,
packaging etc.. in those critical functions. I think this was
a second goal of the certification program. As it already
raised 10 000 euros with only 500 certificates delivered, and
given that very few of us started to sell them, this makes me
optimistic about having enough ressources in a close future to
secure such roles. <br>
</div>
</div>
</blockquote>
<p>10 000 euros doesn't sound like much to me. <br>
</p>
<p>Think about how much each of you could earn if working as a
contractor today.</p>
<p>How much documentation work is required for each technical
feature coded? Maybe 30% of the coding effort to document the API.
Maybe over 200% if you additionally consider updating videos,
training courses, and translations as well.</p>
<blockquote type="cite"
cite="mid:CABgOYCc3LXK5XCd-hmqSsSMNNw8hULM1kOuMNy-5RvpCxF52Sg@mail.gmail.com">
<div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p> </p>
<p>We keep seeing training courses created and not given
back to the QGIS core. For this I think we need to target
the business case of people putting on courses. Firstly,
educate users about which courses the QGIS community likes
(namely ones which integrate and contribute to QGIS docs).
It is good business to go where students are being sent.
Then lets help make it easy to bring material back into
our core material. It is expensive to integrate your
personal course with external material. This is something
that a "community builder" could really help with and
spend time on, especially with the first couple of
course(s) we bring in. As above, define to Universities
what we expect of them to be good open source citizens.
And help course writers to write a business case to
collaborate. (Info at: <a
href="http://cameronshorter.blogspot.com/2018/10/the-open-business-business-case.html"
target="_blank" moz-do-not-send="true">http://cameronshorter.blogspot.com/2018/10/the-open-business-business-case.html</a>
)<br>
</p>
<p>I really think that we can reduce the barrier to entry
for QGIS docs people. For OSGeoLive, we went from hardly
attracting contributors to attracting scores of volunteers
by modularising and making it easy to contribute, along
with asking, and following up. QGIS will be harder to
move, but I'm convinced it is achievable following a
similar formula. In particular, we can help techies become
good writers by having a senior tech writer offer to
review the docs written (in line with templates we plan to
build with TheGoodDocsProject. Initially this reviewer
might be the community builder, but it could become a
separate role.<br>
OSGeoLive story here: <a
href="http://cameronshorter.blogspot.com/2011/06/memoirs-of-cat-herder-coordinating.html"
target="_blank" moz-do-not-send="true">http://cameronshorter.blogspot.com/2011/06/memoirs-of-cat-herder-coordinating.html</a></p>
<p>I'd have the "community builder" lead the breaking of
tasks and docs into sections, then reaching out to groups
people and inspiring them to take on a task or two.</p>
<p>I'd also suggest setting up periodic meetings, probably
weekly. These are really good for keeping the momentum
going and inspiring each other.<br>
<br>
</p>
</div>
</blockquote>
<div>Well, I think that on this part the documentation team is
doing great coordination and leadership. I think, they ask for
more manpower mainly. <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p>Rosa, re videos: Yes, they are great for users. They are
also very time consuming to maintain and update with each
release. Be careful to ensure that you only create as much
material as your team have the capacity to sustainably
maintain.<br>
</p>
</div>
</blockquote>
<div>True, but I think they tend to become the mainstream
information channel for young generations. I'm +1 to test it.
Go Alexander ! ;) <br>
</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF">
<p> </p>
<p> Re giving awards: I've been researching quite a bit into
motivational theory, which taps into gamification theory.
It talks about intrinsic motivation vs extrinsic
motivation. Why Open Source volunteers so often sustain
valuable contributions for so long is they are
intrinsically motivated - for a greater purpose and higher
goal. Acknowledging someone's good work is worth doing,
but handing out gold stars for effort has the potential
sometimes to cheapen the person's contribution - as it can
be tapping into extrinsic motivation, which is less
sustained.</p>
</div>
</blockquote>
<div>This is really intersecting to have in mind when starting
to contribute. Contributor burn out is a concern, especially
on those moment with so much users relying on us, and not so
much ressources or new comers jumping in. Knowing yourself,
understanding why you are starting to contribute is in my
opinion really important (I just experienced it recently on
myself, so I'm especially keen that we find sustainable ways )</div>
</div>
</blockquote>
<pre class="moz-signature" cols="72">--
Cameron Shorter
Technology Demystifier
Open Technologies and Geospatial Consultant
M +61 (0) 419 142 254</pre>
</body>
</html>