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
