Jl/license

[lav-julien]

Issue

Add the different license items to the rewrite repository so it gets merged at the same time than the rest of the rewrite

Description

Actions to perform are:

• Add a License.txt file for GNU-AGPL
• Add a license badge at the top of the readme file
• Add a license section in the readme file linking to the license.txt file
• Add the workflow for contributions review in the readme file
• Link the contribution guidelines file from Viktor in the readme file

Preview

[VIKTORVAV99]

Just one tiny suggestion, nice choice of license though!

[VIKTORVAV99]

We should probably also update the license information in the package.json files (web, mobile and mockserver) and the pyproject.toml file. Even though we don't publish these packages I think it would be good for clarity and to ensure there are no conflicting licenses in the repo.

[lav-julien]

We should probably also update the license information in the package.json files (web, mobile and mockserver) and the pyproject.toml file. Even though we don't publish these packages I think it would be good for clarity and to ensure there are no conflicting licenses in the repo.

I updated it for the web app, not sure how/where to include it for the mobile app and mockserver though nor pyproject.toml

[lav-julien]

Link not working in the Readme but I guess it's because the PR is not merged, don't know if there is a more robust way to handle this in GitHub

[VIKTORVAV99]

Link not working in the Readme but I guess it's because the PR is not merged, don't know if there is a more robust way to handle this in GitHub

It's also pointing here to the rewrite repository, once it's merged to master it will break again unfortunately.

I would probably link it to the license file in the "normal" repository so it works when we merge it to master.

(In either case we have a lot of these small cleanups to do once we merge the repositories).

[lav-julien]

@VIKTORVAV99 do you think we can merge this pull request in the contrib-rewrite and then we can start doing some of these cleanup things? Or what would be the best way to proceed?

Also, for the workflow diagram, I would suggest to upload an image on our repository and then embed it in the README file, let me know what you think about it.

I would suggest this workflow to keep something simple and easy to understand

[VIKTORVAV99]

@VIKTORVAV99 do you think we can merge this pull request in the contrib-rewrite and then we can start doing some of these cleanup things? Or what would be the best way to proceed?

Also, for the workflow diagram, I would suggest to upload an image on our repository and then embed it in the README file, let me know what you think about it.

I would suggest this workflow to keep something simple and easy to understand

Yeah I think this can be merged but someone, @madsnedergaard, forgot to give me write permissions in the fork. 😅

So either Tony or Mads will have to approve it and merge it...

As for the workflow diagram I have been looking into if we can use https://mermaid.js.org/, it should be fully supported by github but I'll have to look up if it works in the mobile app too. Otherwise I think embedding the image is a good idea.

[VIKTORVAV99]

@VIKTORVAV99 do you think we can merge this pull request in the contrib-rewrite and then we can start doing some of these cleanup things? Or what would be the best way to proceed?

Also, for the workflow diagram, I would suggest to upload an image on our repository and then embed it in the README file, let me know what you think about it.

I would suggest this workflow to keep something simple and easy to understand

I have been thinking a little more about the diagram itself and I would probably change the first check, valid code formatting, to something like: "Passes CI Checks". This is because we are not just checking the code formatting but also running unit tests, component test (soon) and full E2E tests not to mention scanning for vulnerabilities so it's a little more than just formatting.

[VIKTORVAV99]

If we use mermaid it would look something like this:

---
title: PR workflow
---
flowchart LR
    PR(New PR)
    CI{Passes CI checks?}
    CIFAIL(Reject)
    REVIEW(Review by Electricity Maps team)
    REVIEWAPPROVED{Approving review?}
    APPROVED(Approved)
    REQUESTCHANGES(Request changes)
    MERGE((Merge))

    PR --> CI
    CI -- YES --> REVIEW
    CI -- NO --> CIFAIL
    REVIEW --> REVIEWAPPROVED
    REVIEWAPPROVED -- YES --> APPROVED
    REVIEWAPPROVED -- NO --> REQUESTCHANGES
    REQUESTCHANGES --> REVIEW
    APPROVED --> MERGE

Loading

The benefits of this is that we can make it interactive and potentially link to more resources if needed.

EDIT: We can color them as well I just didn't do it for the example.

[madsnedergaard]

I just added the license to mobile and pyproject files. I also changed it to use AGPL-3.0-or-later, which is the "official" identifier (see https://spdx.org/licenses/) :)

Regarding the diagram I think we should just use an image for now to keep it simple, but I prefer @VIKTORVAV99's phrasing of the first step. I also think "reject" is a bit too harsh, maybe we can say "request changes" and point it back to the CI check or something similar?

[VIKTORVAV99]

I just added the license to mobile and pyproject files. I also changed it to use AGPL-3.0-or-later, which is the "official" identifier (see https://spdx.org/licenses/) :)

Regarding the diagram I think we should just use an image for now to keep it simple, but I prefer @VIKTORVAV99's phrasing of the first step. I also think "reject" is a bit too harsh, maybe we can say "request changes" and point it back to the CI check or something similar?

Maybe just make changes instead of request changes?

Image will probably be best too, mermaid don't really seem to work on mobile as it should.

[lav-julien]

I just added the license to mobile and pyproject files. I also changed it to use AGPL-3.0-or-later, which is the "official" identifier (see https://spdx.org/licenses/) :)
Regarding the diagram I think we should just use an image for now to keep it simple, but I prefer @VIKTORVAV99's phrasing of the first step. I also think "reject" is a bit too harsh, maybe we can say "request changes" and point it back to the CI check or something similar?

Maybe just make changes instead of request changes?

Image will probably be best too, mermaid don't really seem to work on mobile as it should.

I uploaded a new workflow in the main path (let me know if we should store it in a specific folder).

I think we could merge the PR now and start fixing the links. Let me know @VIKTORVAV99 if you agree

[VIKTORVAV99]

I just added the license to mobile and pyproject files. I also changed it to use AGPL-3.0-or-later, which is the "official" identifier (see https://spdx.org/licenses/) :)
Regarding the diagram I think we should just use an image for now to keep it simple, but I prefer @VIKTORVAV99's phrasing of the first step. I also think "reject" is a bit too harsh, maybe we can say "request changes" and point it back to the CI check or something similar?

Maybe just make changes instead of request changes?

Image will probably be best too, mermaid don't really seem to work on mobile as it should.

I uploaded a new workflow in the main path (let me know if we should store it in a specific folder).

I think we could merge the PR now and start fixing the links. Let me know @VIKTORVAV99 if you agree

If we add more assets it might make sense to create a specific folder for it (something like "doc assets" maybe.

I think we can merge this now unless @madsnedergaard has anything he would like to add.

Then I'll update the contribution guide document to reference the new license as well. (BTW we will probably cut out most of the existing contribution guide in the open PR and put it in the wiki step by step later).

[madsnedergaard]

Hurray, amazing work! Thanks both of you 🥳