ROADMAP (for now)

[giobber]

General

• Prepare branch develop
• Choose to Use Django 4.2 LTS version when ready
• Add setuptools to improve dependency management (NOTE: using pyproject.toml to be more future-proof)
• Add to .gitignore IDE specific folders (.idea, .project, .vscode, ...)
• Define workflow for internal developer (gitflow?)
• Define workflow for external contributions
• Define a versioning system

Documentation

• Choose what library/strategy to use
• Insert database structure
• Insert how import file are structured

Backend

• (WIP) Define a flowchart for DB structure (at least containing Member, Membership and Course
• Define how User authentication should work (as see here it's problematic to change later)
• Insert models Membership and Course/Event

Frontend

• Add template system
• Add base template
• Add bootstrap as SCSS/JS dependency
• Add SCSS support with django_compressor and django-libsass
• Create user profile page

[ZompaSenior]

General

Define workflow for internal developer (gitflow?)

I've discussed this point with @Umuril yesterday night, and I think we have to definitely choose gitflow.
We both use it at work, also with some collaboration with colleagues, and it works very fine.
I will try to describe how can we use it:

• main no work here, only merge and tag (named v1.0.0, v1.0.1 and so on) for the versions we are going to release. In case some bug are found in production, you have to create a new branch hotfix, correct the bug and merge on main again.
• release I had a little misunderstood this at the beginning, but here it is necessary to merge the version which is considered ready for release from develop, but which must be tested, in practice a release candidate, here you can work, but only if there are corrections to be made. Whene ready you can release merging on main
• develop this is the branch on witch go on the main application development, but, here too, no work direct on the branch, other branch named feature/<short-name-for-the-feature> have to be created, the work is made on them, and after merged on develop. hotfix branch too have to be merged here, in order to collect that corrections for the future

At the beginning, all these structure seem useless, and maybe it is, but for me is important start with the right step.

If you look at my fork branches, I started to work on a branch named feature/startup, but maybe we can assign some part of the development one each other, and create branch for them, and in some moments align the work merging on develop.

Anyway I put here a link with an image that is very clear to me, with some explanations: gitflow

[ZompaSenior]

General

Use Django LTS version (3.x)

I have double checked the scheduling of the supports to the various versions, and I made a consideration: the 4.2, that is going to be the next LTS, will come out on April 2023. I don't think that we are going to be in production before that date, so maybe we can use the 4.1, and switch on the 4.2 when released (normally there are not big changes in minor version change).

Do you agree?

[giobber]

We are on the same page
Actually I've specified in dependencies a generic "Django>=4" and pip-tools resolve it with a django==4.1.7
On April will fix a specific version

[ZompaSenior]

Documentation

What to use? (github compatible is preferable, maybe jekyll???)

I have no doubt about that: Sphinx!
We can automatically collect documentation from comments in the code, and automatically publish it as GitHub pages. I have used, and it is simply fantastic.
This is also very useful, because it forces you to write many comments and well done.
I usually use this standard from Google, that is very clear for human, and functional for Sphinx.

[giobber]

Jekyll is very nice if you need a simple and tight documentation, also is very customizable, you can create a full static site with it if you want
Sphinx...I've tried to use it some years ago and failed, too complex for my use cases, but here it could be the right tool
I'm on your hands on this...especially if has automatic generation of documentation

That google standard essentially says "USE PYLINT"
Actually dev dependencies require installation of black which is a more opinionated linter than pylint but with nicer defaults. Also I use isort (with black compatibility mode enabled) to better reorder import statement

Using established common standards for linting and code formatting is essential to avoid constant generation of reformatting commit and make more simple for new developer to join the project as they don't need to learn new rules for formatting their code or hit their head for changing IDE configurations

[ZompaSenior]

Backend

(WIP) Define a flowchart for DB structure (at least containing Member, Membership and Course

If is OK for you, I will go on to describe the structure in my ER Diagram, and them we can discuss on them together.