We plan three sprints of about twelve days of development each. Issues require from a couple of hours to several days of work, and we assume that in average we can tackle a dozen issues during each sprint.
You’re most welcome to give feedback to help us prioritize and refine the backlog by replying to this post. You can also register to the git to put thumbs up and comment issues.
But to avoid duplicates, please read carefully the 354 open issues before creating a new one:)
Please share feeback about what matters most to you, from to bug fixes and small enhancements to incredible features, to help us find the best path to a make Mobilizon a super great tool !
And if you make custom developments, please let us know thanks to a MR or any other way and we’ll consider adding them to a sprint.
I must admit that the development prospects for Mobilizon are already very good, in addition to the fact that the system already works very well.
The only implementation I’d like to see your development team consider is to allow, possibly with the approval of the instance administrators or managers of the individual Mobilizon « organization account, » events published by other federated platforms that can manage the event object, such as Friendica or Bonfire, or WordPress (suitably equipped with the events-bridge plugin). It would also be interesting to even allow Mastodon users to compose appropriately formatted messages to create a Mobilizon event. But this is probably science fiction, especially given Mastodon’s format limitations.
I understand that this implementation may seem superfluous, but I want to point out that when Lemmy allowed any Mastodon user to start a new thread, Lemmy became a point of reference for the vast Mastodon community.
What about issues that were closed because there are too many open ones? I think almost all my issues are now closed because of that, regardless of whether it’s a feature request or a bug report.