Decidim.GOV: Democratic Governance for an open community
#decidimgov Internal organization, democracy and decision making
[ES] Sistema para valorar el impacto de nuevas funcionalidades / [EN] System to assess the impact of new functionalities
[ES] Establecer un sistema para valorar el impacto de nuevas funcionalidades o cambios en el código. Poder clasificar las mejoras utilizando por ejemplo las mismas categorías del método Semver (major, minor y patch).
*MAJOR: cuando se hacen cambios incompatibles con la API
*MINOR: cuando se agrega funcionalidad de manera compatible con la versión anterior
*PATCH: al hacer correcciones de errores compatibles con versiones anteriores.
[EN] Establish a system to assess the impact of new features or changes in the code. To be able to classify the improvements using for example the same categories of the Semver method (major, minor and patch).
*MAJOR: when you make incompatible API changes
*MINOR: when you add functionality in a backwards-compatible manner
*PATCH: when you make backwards-compatible bug fixes.
Report inappropriate content
Is this content inappropriate?
15 comments
Conversation with Carol Romero
ping to Sílvia Luque @elaragon @virgile_deville @josepjaume @robertgarrigos. Añadíos a la propuesta y editad, corregid, añadid! :)
Silvia @SilviaLuque
Buenas, me gusta esta propuesta, pero no sé si el proceso de gobernanza tiene que extenderse tanto en los detalles del proceso de diseño del software. En todo caso me encanta y me parece muy importante este punto. Sin embargo creo que la categoría "Toma de decisiones y resolución de conflictos" tiene que abordar otro tipo de problemas, como son: "quién puede convocar una consulta?", "quíén y cómo se puede solicitar un cambio de un órgano?", "qué pasa cuando un comité no se pone de acuerdo?", "quién y cómo puede decidir si se disuelve la asociación?", "echar a alguien?" cosas de ese tipo. Para no complicarlo todo más propongo crear una subcategoría para el tema del software, o incluso una categoría a parte. No lo sé!
Estoy de acuerdo contigo @xabier, temas de software mejor dejarlos bajo la batuta del grupo técnico. Además en un momento puede irnos bien una metodología pero en otro momento quizá descrubrimos que hay otra que nos va mejor.
De todas formas esta propuesta me gusta, aúnque quién i como decide la clasificación?
@xabier @oliver_valls las propuestas oficiales que habían de partida en esta categoría eran relativas a la toma de decisiones sobre el roadmap, así que nuestro grupo se centró en estos temas más técnicos. Si a eso añadimos que teníamos varios devs en la mesa... :)
Las subiré igualmente para recoger el trabajo colectivo de la sesión, aunque en algún momento podrían pasarse a una categoría específica. De esta manera el comité técnico tendrá ya un conjunto de propuestas con el que empezar a trabajar.
Vaya, supongo que heredamos algunos problemas entonces @carol, En todo caso tenemos que decidir qué hacer con todas las propuestas de gobernanza de código, porque claramente ese aspecto está muchísimo más desarrollado que el que necesitan los estatutos o las bases de la forma jurídica que necesita la comunidad.
@microstudi me faltabas tú!! vente! voy a subir el resto de propuestas que hablamos en el grupo
¿Qué hacemos entonces con propuestas como esta y 2 o 3 más que tengo pendiente de subir? Las dejamos a la espera de cuando entremos a concretar este aspecto? Entiendo que para el proceso actual no son muy útiles.
Pues para que no se pierda el trabajo yo creo que lo que podemos hacer es: crear una nueva categoría, meter allí estas propuestas y luego si se aceptan pasarlas como normas del proceso de Roadmap. La nueva categoría podría llamarse: gobernanza del código o así.
Conversation with Virgile Deville
We talked about being more data driven in our approach to accept new functionnalities.
Data could be quantitative such as data usage justifying a change or even a detailed user story based on a real usecase.
More generally, I'm thinking that we could add a proposal about MetaDecidim being an organization that will have to be in part data driven (meaning not only data will guide our actions). Measuring accurately impact and change instigated by Decidim using well defined metrics will be key to take the right decisions in the future.
As @SilviaLuque has worked on ways to evaluate participatory processes maybe she can also point us in the right direction for this.
I totally agree. This would be really great, and one of the original goals of the project. It is, however very hard, and we need a lot of data to do that properly. But I would be really great.
Nevertheless I suggest we leave some of this development aside, so we can focus on the core-organzational structure of the community and built some technical specifications for later. We otherwise risk to get lost on the details. And we need to make progress :)
Agreed let's keep it simple at first. This a super massive task that will require heavy research.
Hi! I'm publishing this draft (today ends the period for collaborative proposals) and we'll move it to the category "Code Governance". There I have added some other proposals that we discussed in our group.
- [ES] Proceso para aceptar contribuciones a la rama master / [EN] Process for accepting contributions to the master branch
- [ES] Toma de decisiones basada en la evidencia para nuevos desarrollos / [EN] Evidence-based decision making for new developments
Thanks @carol I just realized we have a bug when publishing a collaborative draft, which is really sad. We loose collective authorship: [ES] Sistema para valorar el impacto de nuevas funcionalidades / [EN] System to assess the impact of new functionalities
Oh no! We need to fix ASAP since this is one of Decidim's most valuable features!
Add your comment
Sign in with your account or sign up to add your comment.
Loading comments ...