Gobernanza tecnológica

Propuesta oficial

A partir del 2019 se define una gobernanza público-común del código, gracias al convenio firmado entre el Ayuntamiento, la Asociación Decidim y el Consorcio Localret. Representantes de estas tres entidades pasan formar parte del equipo de Producto, y son las encargadas de velar por el código.

El equipo de Producto es el encargado de definir la hoja de ruta del software y responder a las propuestas de nuevas funcionalidades que hace la comunidad en Metadecidim. También garantiza la coherencia y sostenibilidad técnica del software. La hoja de ruta se hace de manera colaborativa de diferentes maneras:

A través de Metadecidim y la comunidad (metaproposals)
A través de contratos con la asociación (ex: Vocdoni y el módulo de Voting)
A través de los contratos de desarrollo del Ayuntamiento de Barcelona

Preguntas para guiar el debate:

¿Cómo podemos asegurar una buena gobernanza colectiva del código y de la dirección estratégica del producto?
¿Cuál debe ser el rol de la Asociación en Product? ¿Qué órganos de la misma deben estar representados? ¿Qué actores y qué capacidad de decisión deben tener?
¿Qué tipo de mejoras queremos priorizar? ¿Qué criterios deben usarse para priorizarlas?

¿Cómo puedo participar?

Dejando tus comentarios a continuación. Puedes responder las preguntas o escribir tu reflexión sobre el tema que se aborda en este debate.
Vota los comentarios con los que estés de acuerdo. Los votos serán tomados en cuenta la hora de redactar el documento.

Recuerda expresar tu opinión de forma respetuosa.

Empieza - Finaliza

14 abr 2023 → 25 may 2023

Participantes 9

Grupos 0

Detalles del comentario

Mejor valoración

Reciente

Más antiguo

Más discutidos

Estás viendo un solo comentario

Ver todos los comentarios

Andrés

12 meses

Regarding the features' prioritization, I've just wanted to mention that some years ago we actually tried to do some voting for which features we should develop. I think it was around 2018, and it was actually the begging of the current "Propose new features" process (that's why the slug on that process "roadmap" 😅 ). The problem with this approach was that the proposals for this process weren't too much refined, and they didn't have a good budget estimation, so much of what was decided there wasn't fully implemented but only partially. Also, the development process was really slow, because of the public contracting law times.

Some months down the road, when in the Product Team we were 4 active people in GitHub, I started to notice that we were driving the developers crazy. I started to see a pattern, where coders had a doubt regarding a feature, and we will leave our personal thoughts in the issues, without a clear instruction. This was an issue because what they were actually asking for was a clear and unique direction. During that time I've read a lot about Scrum and how to improve our development flows, and one conclusion that I've arrived is that "too many cooks spoil the broth". This means that even though in the Product Team everyone can have opinions, only one (the Product Owner) can actually make some decisions when there isn't a clear path.

Xavier

12 meses Editado

Hi Andres,

Some thoughts based on my several experiences on product management.

First getting to know Scrum is a very good start as it helps make a well known basic governance for the product team between developers, stakeholders and the Product Owner.

But in my point of view there will be always a great influence of the Product Owner (and Decidim need one). However it is important to make the work of the Product Owner as collaborative and transparent as possible.
- Seek feedbacks
- Include the community for opinion about next features and vision of the project
- Publish the roadmap in an easily understandable way
- The Roadmap can change overtime it is ok
- The vision can change, but it shouldn't be up to the Product Owner to do it, it should be a collective work.

Some ideas about tools to use and for what :
1. Keep Github for technical things
2. Have a place to exchange about new propositions, issues that do not need technical knowledge and welcome simple users. (add, comment vote etc.). And also give information on what is coming next. Open Source tool like https://fider.io/ are great for that.
3. Meta Decidim : to inform, work on the vision and help to engage on key decisions.

Idea on process to put in place :
1. Regularly have live cession to collect feedback and build the strategic Roadmap. (the work of Jeremy Jarrrell is a good inspiration in my point of view : https://www.jeremyjarrell.com/strategic-agile-planning/)
2. Define the need and requirement for next release
3. Give visibility on future release.

Happy to help on this

Lucien Langton

12 meses

@andres I'm chiming in... :) I'm tempted as well to add one key aspect of collaborations around a roadmap: release hypothesises and metrics.

By never being affirmative in building a product, but rather expressing the usefulness of a release around a hypothesis to test, this creates a collaborative mindset of learning together which is way more inviting to multiple stakeholders.

If release objectives are expressed as such and accompanied by metrics to determine the success or failure of the release, product development becomes somewhat simillar to dynamics of distributed governance : rather than opening up a space where everybody competes to have their own feature included in the release, it opens up a space where everybody's goal is to learn to build a better product together, iteratively.

Finally, learning will also be necessary to find the right processes and tools to make this happen for Decidim, as every organization is different :)

Xavier

12 meses

Totally agree :-)

Andrés

12 meses

I mostly agree with what you've said, with only a couple comments to make:

Publish the roadmap in an easily understandable way

This is what we have in https://github.com/decidim/decidim/projects/16

It's important to note that there are some features in the Roadmap that we actually can't publish, like the future contracts that the city of Barcelona is working on. That's because there's an equal of opportunities principle in the Public Contracting Law. This means that if we publicly share these features before the contract is actually published in the Tender Portal, then we could receive a lawsuit as the companies that are in the Decidim community would have the information before this is available to other companies.

Have a place to exchange about new propositions, issues that do not need technical knowledge and welcome simple users. (add, comment vote etc.). And also give information on what is coming next. Open Source tool like https://fider.io/ are great for that.

On our case, for the prioritization of proposals we like to use Decidim itself, as we believe that's the best way of knowing/using/seeing the limitations of the software (aka Dog-fooding). To keep things clear and not break communities expectations, we use Endorsements as a way of measuring the acceptance that the Proposals have in Metadecidim.

You have more information on how this process work in https://meta.decidim.org/processes/roadmap (It was recently updated, a couple of months ago)

Xavier

12 meses

Thank you for clarifying, my point on the roadmap is making it more visible/accessible, it exists in Github, but what about non-tech users that are not used to dig for this kind of information ?

On new proposals :
I feel half half. It is interesting to use Decidim to get new features proposals, but as a same time I don't feel it is the right tool to do it, as it is not that easy to navigate in every proposal and as it is on a rolling basis.
Why not using it to plan next release with a several step process instead, may be like :
1. Call of proposal for 3-6-12 next month
2. Next feature proposal from Product Team
3. Feedback from community
4. Confirmation of features in next releases (and what is supposed to be planned next)

Maite López Sánchez

12 meses

I really like the Dog-fooding idea from @andres for using Decidim to prioritise proposals of code improvement, if it has limitations we need to be aware and try our best to overcome them.

Lucien Langton

12 meses

Great debate!

I'm in general support of dog-fooding, except if it stays in the way of improving the development of the dog-food ^^ Waf ! ...Let's not forget:
A: we are not all dogs (some of us are cats!)
B: Participatory democracy and agile software development are very different things (both equally important!)

From what I see, the main thing missing from decidim now to use it for roadmap planning are:
- Speaking as roles (product owner, front-end dev, back-end, infrastructure, quality, UX designer, etc)
- - Which means : defining them: their purpose, accountabilities, rights

Why is this important ?
- Defining roles brings clarity to processes. As everything, product design & dev is a learning path. Experimentation needs clarity to learn together and move forward.
- Defining roles will also bring attention to what roles are missing :) i.e. accessibility tester? community represented (to plan release parties and streamline feedback ?) ...
- Clarity and rigidity are 2 very different things: roles will adapt and change as new collective learnings are made
- clear processes will enable participation from people outside the team

Perhaps Decidim can be configured to speak in roles, but let's look at it this way : could a specific tool make harm to the project ? Is this sure ? What could be gained ? What else is possible ?

Referencia: MDC-DEBA-2023-04-249
Versión 6 (de 6) ver otras versiones

Esenciales

Preferencias

Analíticas y estadísticas

Marketing

Gobernanza tecnológica

Preguntas para guiar el debate:

Por favor, inicia la sesión

Configuración de cookies

Esenciales

Preferencias

Analíticas y estadísticas

Marketing

Cerrar debate

Gobernanza tecnológica

Preguntas para guiar el debate:

Confirmar

Por favor, inicia la sesión

Compartir