= Hack call: 14:00 UTC =

	* Radicale improvements (James)
		* Use uwsgi for radicale 2.x
		* Bug #917188 to discuss config used in !FreedomBox
		* default rights file included in package: https://salsa.debian.org/debian/radicale/blob/master/debian/etc/radicale/rights
			* Confirm if this allows users to share calendars
	* Merging snapshots into storage module
		* https://salsa.debian.org/freedombox-team/freedombox/issues/990#note_58737
		* To make the module essential in next release
	* Snapshots will not fill up the disk anymore
	* Plinth will be removed from testing on 10th Feb
		* Due to bugs in mod-gnutls
		* Possibility of replacing mod-gnutls with apache openssl module
	* Don't show unused applications in the UI for the buster stable release, enable them later
		* Unused apps
			* BIND
			* Tahoe-LAFS
			* !MonkeySphere
		* This avoids a lot of unnecessary questions
		* Avoid user confusion
		* Another option is to move them to an "experimental" section
			* "Enable experimental modules" can be a global setting which toggles whether these modules are visible or not
			* Add a banner to the module itself?
	* cockpit-docker experiments (sunil)
	* Separating must haves and nices to haves for stable milestone (sunil)
		* Backups issues are must-haves
		* Individually, we'll split the list and elect items onto the list. If there are any disagreements, we can discuss
		* https://salsa.debian.org/groups/freedombox-team/-/boards?scope=all&utf8=%E2%9C%93&state=opened&milestone_title=Buster%20stable%20release
			* Items tagged "To Do" are must-haves. The nice-to-haves remain in the Backlog.
	* Updating the UI by Buster freeze (Danny)
		* What updates do we consider high-priority? (These will appear on Buster milestones, might possibly appear in Buster stable release depending on what we can do)
			* Logos issue
			* Manual link says "Learn more" and we change that to "Manual" with an icon
			* Sometimes the margin on the top is not the right size, we can correct that
			* Adopt theming for form widgets, like checkboxes and dropdowns
		* Items for post-freeze or buster stable backports: 
			* UI update to display the current status of each app, like running status, diagnostics, installation status
		* Existing issues (not action items, just listed to provide historical proposals):
			* Installation UX: https://salsa.debian.org/freedombox-team/freedombox/issues/1418
			* Backup card UI: https://salsa.debian.org/freedombox-team/freedombox/issues/1396
			* Software upgrade UI: https://salsa.debian.org/freedombox-team/freedombox/issues/1377
			* Card style: https://salsa.debian.org/freedombox-team/freedombox/issues/1311
	* Retirement of !DreamPlug and Raspberry Pi 1 (Danny)
	* Security concerns for PHP? (Danny)
		* Should this stop us from adding PHP-based packages like !WordPress and Nextcloud?
		* There is also a thread on the mailing list about this
		* Mediawiki and nextcloud have excellent security teams who sidestep the security mishaps of PHP. We can trust these packages because of the development communities behind them.
		* Add a page on wiki to discuss why we don't have an app on freedombox. Most of the time, the answer is that we don't have the time to package an app. But also we should welcome new contributors.
		* PHP packages require a lot of effort from security engineers. Mediawiki has the resources to handle these issues, but not all PHP-based packages will.
		* it could be that Mediawiki and wordpress have a lot of security issues because they have so many users, and not PHP.
		* Our problem: we have to decide for other people. There are alternative wiki and CMS packages that aren't written in PHP.
		* We should look at threat model of a typical user of freedombox. most users don't manually install plug-ins, so they have fewer threats.and the incentive to attack wikipedia is greater than attacking anyone !FreedomBox's mediawiki instance.
		* a second option could be putting a big red warning on plinth to recommend that users know the risks before exposing some apps on the public internet. this could be added to any potentially targeted adds
		* we should document the risks and benefits on the wiki
	* Hardware kits (Danny)
		* Next step: test hardware units
		* There is a workaround for the micro that we might be able to apply to the LIME2. And the kernel updates might have solved a problem. 
		* Anyone with a rev. K (latest revision) is encouraged to test it and report any success or failure
		* Any developer with time should feel free to test the rev. k and work on it. a small amount of effort before the buster freeze is harmless
	* Development during freeze (James)
		* During freeze, until release, cannot upload normal releases to unstable.
		* Only critical bug fixes should be uploaded to unstable.
		* New releases on 2-week cycle can be uploaded to experimental instead.
		* Maintain stable branch