search

Datateknologerna-vid-Abo-Akademi / date-website-old

Repository for the new website
MIT License
2 stars 1 forks source link

My proposition #1

Open LinAnt opened 7 years ago

LinAnt commented 7 years ago

Backend stack

For the backend I think our safest bet is to go with django 1.11. Most of our older students are familiar with the framework and Python3.6 is a robust and well supported language. For deployment I suggest we go with current nginx conf and gunicorn. I also think we should go with Postgres as our database solution. It has superb python support and we get a nice abstraction from the old data. Django apps can be reused when updating legacy PHP pages.

Frontend

I suggest we aim for mobile-first responisve design through bootstrap. Bootstrap4 beta is out and it would be nice to try it out.

Development workflow

Do we need a dev branch?

  1. Create issue / choose issue
  2. Branch out from master
  3. Commit/Push
  4. Create a PR with tagged issues / Run tests through TravisCI (free for open source)
  5. Get approval of the herd
  6. Squashmerge

Linting and formatting

Features

Ja tror int de lönar sig att köra WP/motsvarande om vi vill att folk ska kunna contribute:a fritt osv.

oj-lappi commented 7 years ago

Comments on Front-end:

While bootstrap is nice I think the best option would be to collect the requirements first and see if we even need it. CSS3 and responsive designs are pretty powerful on their own, especially if we don't need to support Internet Explorer.

Question: Do we want to support Internet Explorer? Suggestion: Opening the page on IE redirects the user to https://www.mozilla.org/en-US/firefox/new/?scene=2

I suggest we iterate a few times on some wireframes before we start implementing the pages.

Process

I propose we use a clear road-map and regular milestones in some fancy project followup system/just a spreadsheet. Also propose we get estimates early from whoever is doing what so we have a ballpark figure of the amount of work we have.

Also: I've created a front-end team, anyone interested please join it.

wictory commented 7 years ago

Pull requests

My view is that the beginning of this kind of project is difficult, especially when many people are involved. The git model enable anybody to send pull requests with their proposal.

Minimal viable product

My suggestion is that we start with a minimal viable product, and continue/iterate from there. For example if we could build a entry page where none of the buttons work. When the project is this far, it is easier to have a discussion on how the graphical design should be done, what technology should be used, etc.

If some person or some group of people has a vision on how to start, I think the best would be to create a minimal viable product and send a pull request. If we have multiple visions, there are multiple choices to choose from where to pull.

Process

I think it will be wise to keep as much of the process here on github and not spread it out over the internet. In this way it will be easier for new people to get into the project and follow the history of the project.

A roadmap is probably good to have, and @LinAnt already wrote out some features that the app should include.

We could create github issues when we know which tasks should be done. I think we know more in detail what the tasks are when some kind of initial framework is in place. (when we know if bootstrap should be used, and so on)

We could also have a look at gitlab projects (the tab right of Pull requests) and see if that could be used, so that we can keep as much of the management as possible here on github. After a couple of years no one will know where to find the related stuff which is spread all over the internet.

So, I propose that "someone" makes a minimal viable product and sends a pull request.

Other stuff

@oj-lappi what is a team and where can it be found?

oj-lappi commented 7 years ago

Process

I support the MVP way. I agree that as much as possible should be contained on github. What I meant by the project management related mentions was some way for an individual or group of people to keep track of how we're progressing, so there is a clear status of the project, and we can set more realistic dates for release and do some scoping/other management actions if needed.

This would of course be transparent and reported on github, perhaps in a separate repo? It doesn't have to be complicated, but some way of combining remaining estimates with active contributors to get a status view.

It could be as simple as some notes that would be uploaded every regular interval, once a month, once in two months, etc. Just some form of status reporting process.

I'll take a look at the projects tab

Other stuff

I added a slack: slack Added this to the README as well.

We should probably hold a face to face meeting/google hangout, because I'm still unclear on the plan, we can discuss this more on the slack maybe?

Teams

The team is under the org, not the repo https://github.com/orgs/Datateknologerna-vid-Abo-Akademi/teams

wictory commented 7 years ago
oj-lappi commented 7 years ago

I agree that an open set of people should be involved, but I was thinking more along the lines of creating some direction for the project, since I recall Anton already mentioning a planned release schedule.

Doesn't have to be a project manager, could be based on consensus as well.

LinAnt commented 7 years ago

@osoderholm suggested that there should someone responsible for the backend and someone responsible for the frontend.

This could be a person or a small group that can review and suggest improvements on pull-requests to master. Members in this position control all merges to master This way we can ensure quality standards and at the same time give people constructive feedback on the code they write.

MaZZly commented 7 years ago

I could help with code review on backend/frontend code as I've got about 4-5years of experience with Django, working almost daily with it. Also because I've helped maintain code done by inexperienced developers, which is something I don't ever want anyone else to experience.

Frontend frameworks

As for frontend frameworks, I'd personally go for BS3, as BS4 has barely been launched and will probably have several minor issues still. Another goodie to add: FA4, 5 works as well but will need to acquire a license if so.

WYSIWYG editor?

I guess some magical WYSIWYG features will have to exist for "static" pages? Here we need to find one that is straightforward to use:

here's a list of candidates https://djangopackages.org/grids/g/wysiwyg/

Code style

Force some things already from the start, pre-commit is easy to install and we can share a config that will enforce code is correct before code can be commited, much goodness.

What I'd suggest as a starting point:

  1. Set up base project and initial pre-commit config.
    • remember .gitignore.. we don't want people to commit whatever crap
  2. Hide crucial conf settings under env variables..
  3. set up boilerplate base.html template with: JQuery, BS3, FA4
  4. get LDAP login (will it still be used as auth?) to work with something like https://bitbucket.org/psagers/django-auth-ldap/
  5. Some traceback reporting, I personally like and use Sentry, it has detailed reports and can also be used for issue tracking (If I recall correctly)
    • Might exist some student license for non-commercial/student in the SaaS? Otherwise I know how to setup our own if needed
  6. Static pages and menu items (ordering etc)

Tests?

What will be the requirements for tests? Any commited code should probably have some tests covering functionality etc?