Open israbr opened 6 years ago
Reflexiones sobre el proceso:
Thoughts on the process:
I'd like to favour inmutability, one threaded (until proven otherwise) code. We will be TDD it (probably outside in) Pair programming will be encouraged and when not possible, there will be code review. All the test should be runnable on a local machine and you will be required to run them before PR
Sentiros libres de sugerir ideas sobre qué construir ^_^
Also, feel free to suggest ideas on what to build ^_^
Ya sea comercial o académico, me interesa.
Aquà está mi sugerencia: Editor de documentos interplataforma, offline, basado en archivos, git-backed, editor gráfico de documentos capaz de referenciar commits, branches, etc. desde el repositorio en el que se encuentra alojado.
Además, se podrÃa proporcionar una versión en lÃnea para permitir a los usuarios no técnicos crear, revisar, editar y validar la documentación presente en el repositorio.
Be it commercial or academic, I'm interested.
Here is my suggestion: Cross platform, offline, file-based, git-backed, graphical document editor capable of referencing commits, branches, etc. from the repository it is hosted on.
Additionally, an online version could be provided to allow non-technical users to create, review, edit, and validate documentation present in the repository.
Comment moved to #29, better in other conversation...
I put my two cents:
Both sounds amazing. They don't sound small, straight forward to me (I might be the problem here and not your proposal...). I believe that we should be striving for something short (both in time and scope) so that we can test if "the community" can work like this and get the high from finishing it. How does it sound?
My two cents, I propose a "Niko-Niko Calendar"(Spanish link) project. It sound like a "little project" because is a little project for touchdown with TDD, working together with other humans, frontend, backend, docker...
The project it's a calendar in which every day you see a termometer with the "happiness team". At end of the day, The calendar allows each team member to record, at the end of every workday each me their mood during that day.
How does it sound?
What about a Kanban board?
In this day and age having a tool to organize, prioritize and control multiple tasks is a must. It's a simple project that can be divided in several milestones at the beginning, accepting myriad of new features and complexity in all tiers as soon as needed. For example:
Layer | Basic | Advance |
---|---|---|
Frontend | Structure, look&feel, forms, drag&drop | Websockets? ng2? |
Backend | CRUD for tickets, states | public API? state machine? swimlanes? ml for autotagging? fts? |
DB | basic squema | HA, indexes? |
Devops | basic arch and maintenance | AWS? ELB? microservices? docker? CI/CD? |
Each of the above groups can cover tons of tasks, so I think it can fit many professional roles.
@fejnartal, just found this article: https://dzone.com/articles/adding-a-cms-to-your-static-site-with-netlify-cms, are you proposing something similar?
There was some chat the other day about what project to choose and seems like the Niko-Niko calendar (https://github.com/SVQJUG/web/issues/28#issuecomment-354799602) is winning.
The other suggestions felt like a complete product so I think that's better to try something simple for the first try. That way we could ride the rush of delivering to accomplish something more "meaty".
@jeslopcru would you like to lead/PO the project?
To the rest of you, should we create a Meetup event to define functionality and/or scope?
It's awesome. I'm glad to hear that. Although I never been a PM/PO before.
I think that it's a good idea to create a Meetup/Hangout event to define functionality and/or scope? or do you prefer define a bunch of GH issues in a new repository?
I will try to explain Niko-Niko project a little bit more.
I Attach a dirty mockup for help us.
The idea behind of niko-niko is taking the "temperature" of the team. Niko-niko try to measure the "happiness" of a team that work together
User stories:
Technical issues:
Necesitamos decidir si este proyecto va a ser un proyecto para aprender o un producto. La diferencia es que el primero podrÃa no terminar nunca 😉 (no empecemos una conversación interminable sobre la posibilidad de que ambos sean iguales, sólo elige uno)
Need to decide if it's going to be a learning project or a product. The difference being that the former might never be finished 😉 (let's not start a never-ending conversation about the possibility of both being the same, just pick one)