Flask is a great library with great people and great extensions, but it can be even greater with a structured approach to the community aspect. Being around for 10 years and yet, still maintaining relevance is a feat of it’s own. It’s simple to get started with all while being a battle-proven framework. We also notice that it’s a smooth flow from a proof of concept to production. It also influences other frameworks upto this day. Technically it is sound, no doubt about it.
However, there are many Flask-related issues which deserve some attention. The fix to those issues lies not in mere merges or code fixes. One such example is the plugins/extensions ecosystem. A recurrent and commonly observed pattern is that a project rises in popularity and becomes the de-facto reference for a specific task then the maintainer goes offline, cut off from the project. Sometimes other maintainers themselves have no merge right, leaving the project as good as dead.
Due to many factors, the projects soon become obsolete, less efficient or outright broken. But people still use them sometimes unknowingly exposing their applications to vulnerabilities. One help point from the WG is keep an eye on extensions and prevent those kinds of failures. One concrete initiative is to set up an organization (github) to care about extensions. It will have a minimum required number of developers who are willing to look after those extensions. This can also further the Flask education cause by having mentoring, much like Google Code-In. Another aspect is that the Flask community is very fragmented. Flask people don’t have a point of regrouping. Events are organised and then die peacefully. A community WG helps to knit together the community, making Flask users feeling very welcome. It also encourages Flask users to adhere to a code of conduct when organising events, rather than letting every event be as free electrons. Events will also help to grow the community and introduce new members to the ecosystem, especially if these events can keep a high quality standard consistently. The WG would help independent organisers by providing guidelines and knowledge for hosting great events.
A point to further the Flask cause is the organising of monthly/quarterly Flask chats where people are invited to talk about flask-related issues including projects. One other function that this workgroup may help to achieve is to bring to a minimum, if possible, is the increasing options and fragmentations in the Flask-type of building framework, for example, Hug, Sanic, FastAPI are all taking after the Flask model of doing things and may benefit as one whole project, all streamlined to be able to help increase productivity. (Flask enhancement proposals?) In it’s preliminary stage the WG would prepare the event grants requests guidelines and maybe act as the grants WG members until (if needed) such a body is formed. Lastly the WG would provide guidelines as to its own running and constant improvement and provide a consistent plan of action in this regard.
The WG also endeavours to take care of translations.