On 04.09.2020 13:17, Michael Meeks wrote:
Hello Michael, hello all,
Fair enough =) good point - here are a few questions I came up with.
Please note - it is trivial to ask more questions in a few minutes than
can be answered in a lifetime - but here are a few things I'd love to
know
from each candidate:
let me try to share my point of view and feel free to ask more if my
answers are not clear enough! :)
What is the right list for that ? board-discuss I hope.
well, this one was easy!
We are using this public list for discussing with MC and/or BoD
candidates even if the list name could sound "wrong" for discussing with
MC candidates given that it's named "board-discuss" :)
* many MC members say they want to expand the membership.
Given that LibreOffice is rather static in terms of its
number of those involved in development: coding, UX,
translation, documentation etc.
Let me try to think positive, I agree, the numbers are not huge but at
least they were been quite stable (cf. we are not loosing too many
members if compared over the years) during our 10 years lifetime.
Jokes apart, I agree, a really healthy project should increase the
number of members deeply involved in the Foundation daily life.
+ how do you plan to gain lots of new contributors ?
This is definitely not an easy question, otherwise all the former and
current MC
members would not have had the same problem to manage and solve. ;)
We could try to do some experiments thinking unconventional for finding
where our new potential members are, evaluate what and where they could
contribute and support them for starting to actively contribute to the
Project.
In any case, before starting new projects, it's also important to
finalise the MC dashboard for having good data that could make the MC in
the position to better understand where our members are and where we
could find more of them.
A data driven activity could be the first step from my point of view.
To make a (really simplified) comparison with the development of a
product, before starting to implement the product's features it's
required to analyse what the market is asking for, how and where the
competitors are positioning themselves, draw a roadmap and after that
start to develop the features following a business plan.
For the membership I think the flow could be similar. With the dashboard
we should be able to understand better who are the actual contributors
and in which sectors we are lacking of.
We should understand better why the existing contributors decided to
invest their time in our Project, in which areas and try to make more
attractive the existing contribution areas.
We should also ask to the existing contributors that are not members why
they are not applying for a membership.
Something that I found really helpful at SUSE was the retrospective
recently done by the openSUSE release team after the release of openSUSE
Leap 15.2.
The retrospective was done opening a survey and asking to members,
users, general public willing to spend time answering to the questions a
set of questions about the new Leap 15.2, the experience while migrating
from old versions, fresh installations etc.
The answers were collected, aggregated per topic and discussed in
several sessions (3 or 4 in total), all public, and for each set of
questions we collected what went well and wrong and we identified also a
set of action items per each topic.
In some cases the action item was to say thanks to a particular valuable
contributor or to a team achieving something really good.
In some cases the feedback were negative and we highlighted a way to
improve the process for avoiding issues for the next Leap 15.3 release.
We should not be worried to say thanks a bit more often and, at the same
time, accept criticisms and try to improve. I hope that involving a bit
more the members in the general daily life of the Project could also
make the membership more attractive than now.
Well, this is just an idea but the "general plan" should be shaped by
the full MC and driven by the full group, not just by few individuals.
+ Do you think we expand the membership by accpting
more marginal contributions for membership cf.
https://wiki.documentfoundation.org/TDF/Membership_Role#Contributing
I wrote about "lowering the barriers" in my candidacy statement but what
I meant was not to give the membership to everyone randomly submitting
the application because they started one time LibreOffice on their PC.
;)
+ what effect do you expect that to have on the project ?
I suppose you already got an answer to this but feel free to articulate
and ask more if my answer doesn't satisfy you. :)
* If you've stood before, approximately how many people have
you encouraged to apply for membership ?
Well, every TDF member should also advocate and share why someone should
contribute to the Project and decide to apply for the membership.
Doing the same with the "MC hat" should increase the time spent on this
topic and improve the way to achieve this particular goal.
I'm not used to count to how many people I'm talking to about TDF and
the projects developed under the Foundation's umbrella but I think the
number is not so small.
* How many applications have you voted against ?
I wasn't serving TDF in this role and this question doesn't apply to me.
;)
* Do you believe we should have a half-way house / badge
between membership and non-membership that encourages
a person, and gives the a path via more contribution to
achieve full membership ?
I'm not sure if I completely got your question.
Are you talking about a fixed number of required contributions (cf.
badge) in one or more areas of the Project before being qualified to
apply and ask for the membership or are you suggesting to draw a path
that could guide a new contributor to the needed steps for being part of
the project and become at the end a (long term) contributor and also a
TDF member?
I think that before adding extra barriers we should draw a path and
encourage and attract contributors that at the end could be also new TDF
members.
We already have something in place with the
https://whatcanidoforlibreoffice.org website and the next step could be
to expand the part "how" and "why".
* When there are no concrete metrics (such as translated strings,
code commits, wiki changes, ask comments, etc.) available to
decide on a person's contribution; what is best practice for
MC members vouching for their friends' contributions, and how
should other MC members validate that ?
In the ideal world this is a corner case that doesn't exist but you
know, the
real world is not always so easy. ;)
The MC has in place a good peer-review process and if no-one in the
group can decide if it's better to approve or decline an application,
the first step should be to ask for more details directly to the
applicant.
If also in this case the info are not enough, the next step should be to
ask to the community members if someone has some evidences of that
person's contributions. Usually the local community is the right place
to query in this step.
If also after that step it's still not possible to evaluate and come to
a positive decision, probably the best solution is to reply to the
person that should contribute more and reapply again.
This is something that should be communicated properly, providing to the
person also some advice on how to contribute and in which areas and
could also be a good idea to try to contact that person from time to
time for understanding if there's the need of support and if with the
first "decline" the person is also facing the imposter syndrome.
* To what degree should the MC's decisions & discussion
be transparent (ie. publicly available) ?
Our project is a global one and we have different people from different
countries and cultures involved.
I don't think that the details behind a MC vote should be made public
because again, we could cause the imposter syndrome due to a "public
exam" and a "public vote" (and I'm not considering at all legal
implications ;) ).
Apart from this critical set of info, the workflows, the processes and
all the other activities should be made public and shared and discussed
in advance also with the existing TDF members.
In this "open first" approach all the legal requirements or limitations
that come "by law" should also be taken into account ;)
* How do you believe we can improve the existing election
system - assuming the statutes can be tweaked ?
+ I'm interested in where we have the situation that
being too popular can stop you being able to
engage at all as a deputy - as we saw with
Miklos/Jona in the last MC election, and Kendy
in the last Board election.
Let's try to improve one area at time ;)
Running too many big projects in parallel could bring to a chaos where
the MC members can't really focus on the goals.
Please, keep also in mind that the MC has less people than the board of
directors and the goal to grow the number of contributors and members is
already a challenging one. ;)
Thanks for any answers =)
Thanks for the questions and for the patience for reading such a long
reply! :)
Happy hacking and have a lot of fun!
Marina
--
Marina Latini
IRC: deneb_alpha on Freenode
--
To unsubscribe e-mail to: [email protected]
Problems? https://www.libreoffice.org/get-help/mailing-lists/how-to-unsubscribe/
Posting guidelines + more: https://wiki.documentfoundation.org/Netiquette
List archive: https://listarchives.documentfoundation.org/www/board-discuss/
Privacy Policy: https://www.documentfoundation.org/privacy
