Governança tecnològica

Proposta oficial

A partir del 2019 es defineix una governança públic-comuna del codi, gràcies al conveni signat entre l'Ajuntament de Barcelona, l'Associació Decidim i el Consorci Localret. Representants d'aquestes tres entitats passen formar part de l'equip de Producte, i són les encarregades de vetllar pel codi.

L'equip de Producte és l'encarregat de definir el full de ruta del programari i respondre a les propostes de noves funcionalitats que fa la comunitat en Metadecidim. També garanteix la coherència i sostenibilitat tècnica del programari. L'equip de product funciona de forma col·laborativa. El full de ruta es fa de manera col·laborativa de diferents maneres:

A través de Metadecidim i la comunitat (metaproposals)
A través de contractes amb l'associació (ex: Vocdoni i el mòdul de Voting)
A través dels contractes de desenvolupament de l'Ajuntament de Barcelona

Preguntes per al debat:

Com podem assegurar una bona governança col·lectiva del codi i de la direcció estratègica del producte?
Quin ha de ser el rol de l'Associació en Product? Quins òrgans de la mateixa han d'estar representats? Quins actors i quina capacitat de decisió han de tenir?
Quin tipus de millores volem prioritzar? Quins criteris han d'usar-se per a prioritzar-les?

Com puc participar?

Escriu els teus comentaris a continuació. Pots respondre les preguntes, o bé escriure la teva reflexió sobre el tema de debat.
Vota els comentaris amb els quals estiguis d’acord. Els vots es tindran en compte a l'hora de redactar el document.

Recorda expressar la teva opinió de forma respectuosa.

Comença - Finalitza

14 Abr 2023 → 25 Mai 2023

Participants 9

Grups 0

Detalls del comentari

Més ben valorats

Recent

Més antic

Més discutit

Estàs veient un sol comentari

Mostra tots els comentaris

Andrés

12 mesos

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 mesos Editat

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 mesos

@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 mesos

Totally agree :-)

Andrés

12 mesos

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 mesos

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 mesos

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 mesos

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 ?

Referència: MDC-DEBA-2023-04-249
Versió 6 (de 6) veure altres versions

Essencials

Preferències

Analítiques i estadístiques

Màrqueting

Governança tecnològica

Preguntes per al debat:

Si us plau, inicia la sessió

Configuració de les galetes

Essencials

Preferències

Analítiques i estadístiques

Màrqueting

Tancar el debat

Governança tecnològica

Preguntes per al debat:

Confirmar

Si us plau, inicia la sessió

Compartir