Consider the version management

Eventually, we'd like to remove users who are not active in the community, first step is to collect some participation stats.

AC

• Post participation stats in the following format

Stats 
Start Date -> End Date | Last 7 days | This Month
           Messages | Words | Letters
@Nazzz     40        250     1534
@whoan     40        250     1534
@domichon  40        250     1534
@nohabla   0      0       0

We don't have a DB for elprimo, so we can do the following process:

• Collect stats from the last update
• Count letters/words/messages from that time
• Post new stats

It should have a POSIX interface with the following features:

• Action to the Google Group Membership should be specified: Add, List, Remove
• To Add and Remove members the parameter should be a list separated by comma
• The interface should be self documented
• The interface should have a help

It would be nice for people that don't have premium to see the problem's description

• Onboard message should contain:
  • Welcome message:
    • "welcome to server X"
  • Send group mission and objectives
    • This needs to be established, somehow. It's not a blocker.
  • Send rules of the group
    • This needs to be established, somehow. It's not a blocker.
  • Ask for welcome form data
    • First Name
    • Last Name
    • Preffered timezone
    • gmail (for google group)
    • github handle (for repositories)

Technical notes:

• The form data should be persisted in a database (could be a JSON file, for now)
• It should invoke the G-Group Manager the new member to add to the google group
• It should receive the response from G-Group Manager and reply to the user as follows:
  • In case of success: happy message saying there's a pending invite in the provided Gmail account
  • In case of failure: sad message indicating there might be a bug somewhere, including the error

References:

• We've used the user flow in here

We might be calling the server many times, and sometimes there might be concurrent calls, to make well use of resources/quota and easily handle Discord client initialization we can have a singleton https://refactoring.guru/design-patterns/singleton

Notes:

• It will always listen to messages
• It will intercept the message when new user joins

After creating the server we need to find a way to configure it (either init script or something else like Ansible)

Context:

Nazz: Feature Request: Puede salir el de la semana tambien? sale una vez por semana

We have some limitations with discord API, as it only pulls 100 messages per channel and only a few days of data. At the moment, the bot crawls messages for the last 24h.

We will have weekly and probably monthly stats #37 - we'll need a way to collect those stats for previous days.

An alternative.

• Post daily stats in a single channel only to post these stats
• Maybe disable everyone else from posting here
• Post weekly/monthly stats in a more visible channel like welcome or general
• Construct the weekly/monthly updates from prev daily posts

PS: Consider appending a json file with the stats object for easier management of the data

The folder named "pupeteer" should be "puppeteer"

At the moment there's too much logic in the main app, this issue is to refactor that and make sure there's a better separation of concerns.

The app.js file is a bit messy, and after the introduction of the CLI, things are becoming trickier to follow. Please refactor the file. It's worth looking into the techniques from Refactoring Guru to address this issue.

Description

This one needs more refinement but the idea is that we manage: retrieve, list, potentially create, members gists with problems.

Considerations

• Format of the gist
• Template to fill
• Permissions
• Maybe more..

This can also be done in parallel with the logging issue #8, as we might use logging with error handling.
Also consider a debug mode

We need to communicate in the stats how long folks have been inactive, this might be one way:

Daily Stats
No activity last 24h
List the names here

• Weekly stats will have 3 buckets, over 1, 2, or 3 weeks of inactivity

Weekly Stats
No activity over
1 week: list the names
2 weeks: list the names
3 weeks: list the names

• if a given week doesn't have any users don't show it, eg:

Weekly Stats
No activity over
1 week: list the names
3 weeks: list the names

The approach we're trying is in here.

The idea is to have a google account and use something like puppeteer or selenium to do it for us, managed by the bot

Because the GSuite API doesnt allow to do this if it's neither a Business or Education account.

Reference: https://stackoverflow.com/a/63114546

Currently, the discord client and CLI daemon might leave the app in blocking mode. Mentioned in #54 here

Pick anytime after the daily update, could be anytime after the Daily update on Sunday Night, maybe Monday morning?

I think we can potentially get users' last activity from presence https://discord.js.org/#/docs/main/stable/class/Presence

When enabled add Intents.FLAGS.GUILD_PRESENCES to the client initialization

At the moment we're including all the members with no activity last 24 for daily stats and the last 7 days for the weekly updates.

We can rely on the previous week's update and count how many weeks a member has been inactive, this way we'll be able to take action based on how many weeks a given user has been inactive.

We can maybe use the same clock that leetcode uses since that happens every 24h, or we can pick our own cycle (server - cycle).

It should work with Docker and have as default entrypoint the packaged app

We're trying to reduce the noise of daily stats, and we think that weekly stats are enough.

It'd be great if the bot can push the leetcode daily challenge to a channel, so we don't have to manually search for it every day.

Context:

Nazz: podemos poner al @elprimobot a que mande el daily cada vez que salga? asi no hay que dar un viaje pa leetcode para ver el problema del dia

It should have a POSIX interface with the following features:

• Adhoc commands, for example to post the daily leetcode message
• The interface should be self documented
• The interface should have a help

We don't want to allow everyone to pin messages on discord, because it also allows people to delete messages.

An alternative is to give these bits to elprimobot and pin the messages through requests.

AC

• Discord should ping a message when we reply to a message with a reply: @elprimobot pin

When someone has been inactive for a few weeks, they will show up each week, this is not a real problem, but we could improve the UI.

AC

• If someone has been inactive for multiple weeks, only show them on the latest week.

With the packaging system that we have now:

• babel transpiling everything to ES5
• pkg packaging in a static binary

Seems we cannot have top level awaits working correctly:

pkg/prelude/bootstrap.js:1930
      return wrapper.apply(this.exports, args);
                     ^

ReferenceError: await is not defined
    at Object.<anonymous> (/snapshot/elprimobot/es5-packaged/app.js)
    at Module._compile (pkg/prelude/bootstrap.js:1930:22)
    at Object.Module._extensions..js (node:internal/modules/cjs/loader:1159:10)
    at Module.load (node:internal/modules/cjs/loader:981:32)
    at Function.Module._load (node:internal/modules/cjs/loader:822:12)
    at Function.runMain (pkg/prelude/bootstrap.js:1983:12)
    at node:internal/main/run_main_module:17:47

Even though they're supported now since Node v14.8.0

I've been playing around with this babel plugin, but no luck.

Create stub command to receive and respond to commands sent by users in a channel

• Implement decent way of generating logs

When sending messages about leetcode problems, also send a suggested github gist name

Placeholder for posting weekly stats updates

We got an error the last time we tried to retrieve all the members part of the client.

This is crucial for the stats logic, and we need to systematically know who's in the client.

Find a way.

The deployment is very manual at the moment, it would be great to have scripts to deploy everything without worrying about manual error.