Planning the MC meeting

    From The Document Foundation Wiki

    This page was created to organize the topics for discussion at the MC meeting in FOSDEM 2019.

    Dashboard

    Looking at the project presented for the Dashboard itself, this is the skeleton extracted and some starting statements to fill it, in order to propose our feature request.

    While filling I've also tried using DashBoard to query for specific users, and it's already possible, but it just finds few informations and on a restricted range of names. So what should be expressed is that probably just an extension of sources is required for current Dashboard. Please have your say, since I'm not used to this tool at all and I'd want to avoid collecting bad figures asking something that may be already existing.

    Finally, I'm also not sure this is something we need to tender. Probably asking to our devs first could be a good idea, since they may be able to provide such features. I can't figure out how long and difficult it could be to implement them, as I'm not a dev anymore (and never been on web).

    Grant details

    Grant Proposal

    Letting Dashboard be able to allow (MC) to query for specific Community Users, finding infos from several more sources. This could be useful to automate MC's work, but also for the community itself, having just one good tool for everything (For instance for LO months, Google Summer of Code, badges...). And if someday a new platform will be used, it's just about adding it to DashBoard.

    Grant objective

    Create a webpage showing latest activity, summaries and trends of specific users in all areas:

    1. Development
      1. Gerrit and git (already covered)
      2. SourceForge (DLP)
      3. Plone (extensions & templates)
    2. Documentation
      1. Wiki (already covered)
      2. NextCloud (stats on how many files uploaded / modified in Shared Folders)
    3. Infrastructures
      1. Redmine (Dashboard already seems to support it upstream)
    4. Design
      1. NextCloud
      2. Telegram (groups)
      3. Mailing List
      4. Bugzilla (UX)
    5. Translation & Dictionaries
      1. Pootle (OR what we'll use in the future)
      2. Wiki
      3. National versions of LO website (SilverStripe)
      4. Mailing Lists
      5. GitHub
    6. Quality Assurance
      1. Bugzilla (already covered)
      2. Mailing Lists
    7. Marketing / NLP
      1. Slideshare
      2. Mailing Lists
      3. Telegram groups
      4. Facebook
      5. Twitter
      6. Blogs (covered by planet)
      7. NextCloud (stats on how many files uploaded / modified in Shared Folders)
      8. YouTube (TDF / LO channels)
      9. Redmine
    8. user-to-user support
      1. (Mailing lists)
      2. AskBot (Dashboard already seems to support it upstream)
      3. Reddit
    9. etc…

    Grant size

    to be tendered

    Grant beneficiaries

    tender contractor

    Grant follow-up

    Frameworks, languages and tools used should be popular and widely used to allow the result to be community maintained and sustained after initial development. Extensibility should allow developers to refine the tool without deep insight in the used frameworks and tools. Blog posts should advertize the dashboard to the LibreOffice community and invite contributions.

    Suggested implementation

    The Single SignOn platform has already a database with the various usernames of users for the various platforms. So we could just have an extra field in MCM DB to write the reference email stored in SSO. Then DashBoard could gather all those usernames from there.

    Survey

    During last LO Conference (Tirana 2018) we found that a good and probably the best way to gather some more info form our Community users should be via anonymous and optional surveys. TDF has an already up and running instance of LimeSurvey which (also) MC could use for that purpose.

    Why get information about the members?

    The goal of such request is to try growing up our community and possibly membership, but focusing especially in areas we lack from, in geographically terms as well as other kind of areas, which could be gender or age range or whatever could be considered important (languages). Another goal is to have more statistic data to use for marketing purposes on printed materials or on speeches at conferences.

    A dedicated Page is available to collaborate on drafting such Survey's questions.

    MCM Script improvements

    The Membership Committee Management script (mcm-script) is a tool to manage the membership of The Document Foundation.

    Ajusting the time frame for sending renewals

    During the meeting at the LibreOffice Conference in Rome, the MC decided, from a K-J proposal, to send all the membership renewals in the early days of each quarter, instead send in two or three waves with around 20/25 renewals each one.

    The base of the proposal was get more time to handle the renewals, vote and, mainly, get more information to decide about corner-cases. Usually, The MC hadn't enough time to handle the renewals in the last wave of the quarter and, in general, they were decided only in the meeting.

    Then, sending all membership renewals when the quarter stars was accepted as a way to improve the internal process of the MC.

    After decided, we started a test period to check what we should change in the script to confirm the improvement.

    The result of the tests is that only one line in the code should be changed:

    777    if [ $(date -u '+%s') -ge $(date -u '+%s' -d "$base_date - 45 days") ] ; then
    

    This line gets all the members who need to renew in the next 45 days (the '45 days' was the time frame defined to send the renewals in waves. It had been done in every two/three weeks before the MC's decision to send all in the beginning of the quarter).

    This line is part of the code that is run when the MC member-in-duty runs:

    • checking the list of the members to send the renewals first:
    ./mcm notify --renew -p 
    
    • sendind the renewals:
    ./mcm notify -r
    

    gustavo-pacheco

    • updating the database:
    ./mcm push
    

    User story

    As the MC member-in-duty,

    I want to change the time frame in the code from the fixed 45 days to the following formula:

    (last day of the current quarter - today)

    So that I can get the complete list of renewals for the current quarter.

    CRITERIA

    Given I’m the MC member-in-duty

    When I run

    ./mcm notify --renew -p 
    

    Then all the members into the list should have the


    YYYY-MM-DD (current YYYY - MONTH of effective date - DAY of effective date)  equal to YYYY-MM-DD (first day of the next quarter)
    

    Example

    When the MC member-on-duty runs the command to check the renewals to send for the Q2/2019 (after Q2 was started):

    gbpacheco@gustavo-pacheco:~/git/mcm$ ./mcm notify --renew -p 
    

    the result should be:

    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-05-31 (effective date: 2011-07-01)
    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-05-31 (effective date: 2011-07-01)
    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-06-16 (effective date: 2011-07-01)
    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-06-16 (effective date: 2011-07-01)
    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-06-09 (effective date: 2016-07-01)
    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-05-11 (effective date: 2012-07-01)
    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-06-03 (effective date: 2013-07-01)
    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-04-20 (effective date: 2017-07-01)
    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-06-09 (effective date: 2014-07-01)
    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-03-30 (effective date: 2015-04-01)
    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-04-13 (effective date: 2015-07-01)
    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-04-20 (effective date: 2015-07-01)
    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-05-04 (effective date: 2015-07-01)
    would send a renew email for id NNN to NNNN NNNNN (NNNNN@NNN.NNN.NN) to be answered before 2019-05-02 (effective date: 2017-07-01)
    
    

    PS.: the effective date is the date when the membership was formally started.

    List of files

    File:MCM Handling Route LittleAids COM datas.ods

    File:Mcm.zip

    Ajusting the record of the member 386

    For the mcm-db, the membership of our member 386 expires on YYYY-03-31.

    However, for the formal filing in Berlin, his membership should expire only in next quarter (or in YYYY-06-30).

    Because that, the MC member-on-duty should pay attention to it in every first quarter: his renewal should be handled only in second quarter in order to be correct with the formal filing.

    At the moment, we can do it using some tricks based in the difference of the current date and the date of the end of the quarter. The MC member-on-duty can handle it easily but, after the planned improvements of the script, this issue should have a final solution.

    It was already discussed in the previous term and the proposed solution was change the record in the db according the formal filing.

    The proposed change is from:

    status="active"
    create_date="2015-03-30"
    effective_date="2015-04-01"
    renewal_date="2019-03-30"
    renew_notification_date=""
    valid_date="2015-03-30"
    renew_request_date=""
    status_notification_date="2018-04-24"
    status_notification_type="pending"
    lo-email=""
    lo-sip=""
    lo-xmpp=""
    

    to:

    status="active"
    create_date="2015-04-30"
    effective_date="2015-07-01"
    renewal_date="2019-04-30"
    renew_notification_date=""
    valid_date="2015-04-30"
    renew_request_date=""
    status_notification_date="2018-04-24"
    status_notification_type="pending"
    lo-email=""
    lo-sip=""
    lo-xmpp=""
    

    Review of mail messages

    Restarting to send the renewal notification

    Since a long time ago, the renewal notification haven't been sent to the members (however it was not a formal decision).

    Topic to discuss: is it time to restart to send this message?

    Some reasons to do it:

    • It is a way to demonstrate to the members that the process was finished;
    • It is a way to demonstrate to the members that the MC are working on the renewals;
    • It is a formal communication from the Membership Committee.

    Application Form

    • It would be really useful here to add a statement to clarify that money donations are always welcome but not entitling for membership. There are already the check boxes where people assert to have read the statute, so they should already know this, but evidently many just click on them without reading at all. So some few resuming words could prevent good willing people but not so used to read statutes to apply, and MC to answer with template emails. Another way could be searching for currencies symbols within "Contributions" field and pop up some confirmation message, but that's just an idea, still to be discussed.
    • Some stuff about age thresholds could also be necessary, in order to be able to vote and to be elected, but for the last one could be something we ask in the candidacy message. K-J is caring about this aspect.
    • Salutation field should be removed OR left as a free and optional text field. So who wants to be referred in some way (Mr, Mrs, eng., dr…) can specify how, or just not!