wagtail-survey-responses: 7

This data as json

rowid Unnamed: 0 How many sites do you have running on Wagtail? What kind of organisations are your Wagtail sites for? What are your priorities for Wagtail's direction in the next year? Please choose a maximum of three Why have you made these choices? Is there anything else you'd like to see in Wagtail?
7 6 1 Public sector Multi-language, Better performance, Full multi-tenancy They are useful for the wagtail instance of the greek Ministry of Shipping; also we are thinking of implementing more wagtail sites for organizations that the ministry of shipping supervises. We haven't yet decided if it's better to use the *same* wagtail server (using multiple sites) or a completely different one. Both seem to have various advantages and drawbacks... Maybe full multi-tenancy would resolve ths. Yes, I'd like to see the open issue and PR count go to single digit levels! Definitely try to reduce the open issues and PRs in wagtail github; there were open issues and PRs (some for a vert long time) for almost every requirement we had while developing the Ministry of Shipping portal. I think that it's better to focus on reducing the open github issue count than implementing new and shiny features. Actually my recommendation would be to avoid implementing anything new until the issue count is greatly reduced. Keep in mind that a big issue count makes people double think about adopting an open source project, especially for something as fundamental as a CMS. Having almost 700 open issues and 150 PRs does not look good from a managerial standpoint. I understand that developers rarely want to fix broken things or implement functionality that has a lot of moving parts and instead profer to work on shiny new things. Yes I understand that shiny new things may be useful for some cases but when there are fundamental piece of functionality that's missing from wagtail you should focus on that. A final recommendation would be to *reduce* the requirements for merging a PR. The high number of open PRs means that people want to contribute to wagtail but the core developers do not let them! Also I've seen many very useful PRs that work really great but do not get merged because of some non important DRY or architecture related issues. I fully disagree with that. If the code works *merge it* and then open an issue for refactoring if you think that it is so needed. But merge the PRs to get the functionality. Also the contributor doesn't really care about "having a great code standard"; he wants to implement the functionality for his organization; he even goes the extra effort of creating a contribution for wagtail, don't make it harder for him that it should be.