Community governance of Wekan?

[brylie]

Given a recent silence from @mquandalle, specifically regarding the card Todo list feature, it may be timely that the Wekan community discuss forking the project, or at least transforming the Wekan governance structure.

• What would be some goals and impacts of a fork?
• What type of governance structure would the community like to build?

[JoseVega]

I am interested. I´ve been following wekan very closely for the last 7 months waiting for some bugs to be fixed , but it seems to be abandoned. No significant changes in over 6 months.

[xet7]

@mquandalle 's latest comment on GitHub is just 5 hours ago:
oblador/react-native-vector-icons#247

And contributing to Wekan seems to require CLA like this:
https://cla-assistant.io/wekan/wekan?pullRequest=639

So while license is MIT:
https://github.com/wekan/wekan/blob/devel/LICENSE

I don't know how CLA affects license, I'm not license expert.

Then it seems that because wekan has 916 forks, lots of customization and feature additions are made all around, but they are not combined to main repo.

There's a roadmap here:
https://wekan.io/b/MeSsFJaSqeuo9M6bs/wekan-roadmap

But I don't know is that roadmap up-to-date, and what core developers priorities are right now.

[ocdtrekkie]

@mquandalle is likely busy or otherwise disposed, I assume. People get burned out doing solo management of a project like this. I don't think this was a full time gig for them. As to whether or not you should fork, I abstain.

CLAs are effectively a way to prevent a contributor from coming back and suing claiming their rights were violated or some such down the road. But the project is licensed MIT and can be forked like any other MIT licensed code.

Note that generally trademark doesn't go with code, so if you forked you would need to call it something else.

[AlexanderS]

Wekan is already an organization account. @mquandalle could add people to the wekan organization, so that more people can help with the management of the project. @mquandalle could still set the long term development goals, but for example simple bug fixes and release management could be handled by someone else.

[ocdtrekkie]

Sure, @AlexanderS, it depends what @mquandalle wants to do. Adding people willy-nilly has security risks, figuring out delegation is still potentially a lot of effort and time. It's really hard to suggest a path to follow without an opinion from the project's maintainer and those people who care and would put in the effort to work on this project. (At the end of the day, I personally don't care what anyone does, really, because the current Sandstorm package of Wekan does everything I need.)

[JoseVega]

I agree with @ocdtrekkie , I think the current package is pretty good , I´m interested in fixing just a few bugs so I dont think a big fork is necessary. Maybe @mquandalle can streamline the process for contributions and tell us the state of the project.

I understand he might be busy or he can´t afford to spend more time on the project , so maybe we can pay him for his time to review and accept a few patches.

[mquandalle]

@xet7, as @ocdtrekkie pointed out, the CLA is by no way here to restrict user rights on the code, including the right to modify it. Wekan is released under the very liberal MIT license, which allows forks and even re-licensing.

I wouldn’t mind if there were a strong push for a community-governed fork, as the code could still go back and forth between the two “branches”. However that would be a suboptimal model consuming both developers and confused users time, it would be better if people could be satisfied with the governance of this original Wekan repository.

One of the reason I failed to merge recent contributions, is because I focused on making a modular Wekan (basically what I have described here). A lot of different users want to write specific features and integrations, and a model where they can build and maintain these as plugins on top of a small core is appealing. I spent a lot of time trying to build that model, but I think I got lost in my will to rewrite everything. Especially when I tried to use cutting-edge tools (like GraphQL). Writing an open-source platform with a market store where people can publish and install plugins is much harder that I had hoped. And @ocdtrekkie is also right that I got burned doing solo development on Wekan for 18+ months, and at one point I stopped reading the notifications that came all days.

My long-term vision remains pretty clear: make Wekan an open platform for project management. I failed at my rewrite-everything solo plan. So I’m going back to my code-review homework, and I’ll try to associate other developers in the long-run.

[AlexanderS]

@mquandalle Is there somewhere something of your "rewrite-everything solo plan" available, so that maybe other people can help?

[brylie]

it would be better if people could be satisfied with the governance of this original Wekan repository.

@mquandalle what process should we follow to add people to the Wekan organization as managers?

Should we have a brief election to add, for example, two more people as community maintainers of the Wekan organiation?

[brylie]

I would like to propose a process we could initially follow:

1. members of the Wekan community nominate one or more persons other than themselves to be part of the 'Wekan governance team'
2. we cast votes for the nominated people, e.g. using Github reactions (thumbs up only)
3. the top two voted members will become part of the initial 'Wekan governance team'

Alternatively, we might figure out an anonymous voting method, but I think the nominations should come from the community -- with no self-nomination.

[brylie]

I have opened a community governance thread on the Wekan discussion platform.