Implementierung öffentliche Dienstleistungen

[sloschert]

Ich habe mir jetzt mal Gedanken gemacht, wie man öffentliche Betriebe im Sinne der Holländer implementieren kann. Es ist nicht sehr kompliziert, insbesondere wenn man keine neue Entität "Öffentlicher Betrieb" einführt, sondern stattdessen der Einfachheit halber auf Produkt-Ebene das Attribut "öffentliche Dienstleistung" einführt.

Könnte man demnächst mal angehen.

Voraussetzungen:

• Die Entity "Plan" benötigt das boolesche Attribut public_service.
• "Plan" und "ProductOffer" müssten so modifiziert werden, dass der Preis für public services nicht den gesamten Kosten, sondern Null entspricht.
• Pläne, wo publich_service = True, benötigen einen besonderen Approval-Prozess, wo verifiziert wird, dass der Plan auf dem Rätekongress/Plenum genehmigt wurde.
• Berechnung eines Auszahlungsfaktors (siehe unten), der u.a. das Verhältnis von öffentlichen zu produktiven Betrieben widerspiegelt und Anwendung dieses Auszahlungsfaktors in GrantCredit auf alle Member.

Front End:

• Die Betriebe erstellen wie gewohnt ihre Pläne, aktivieren bei der Planerstellung aber eine Checkbox namens "Öffentliche Dienstleistung".

---

(Zur Erläuterung:)

Öffentliche Betriebe sind bei den Holländern ja Betriebe, die ihre Produkte (vor allem aber Dienstleistungen) im Gegensatz zu produktiven Betrieben kostenfrei anbieten. Bildung, Infrastruktur, Gesundheit läuft alles über öffentliche Betriebe. Die Kosten dieser Betriebe werden durch gemeinsam beschlossene Budgets finanziert. Die Budgetkosten werden auf alle Members umgelegt. Diese Umlage geschieht mittels einen Auszahlungsfaktors (FIK). Ist der Auszahlungsfaktor z.B. 0,5 erhalten die Members für 1 Stunde Arbeit 1*0,5 = 0,5 Arbeitsgeld.

Die Formel des Auszahlungsfaktors lautet: FIK = (A − ( P o + R o )) / (A + A o)

wobei P o, R o und A o die Kosten der öffentlichen Betriebe sind, A ist die geleistete Arbeitszeit der produktiven Betriebe.

Hätten wir in unserer Wirtschaft jetzt ausschließlich öffentliche Betriebe, wäre der Zähler Null oder Negativ, die ArbeiterInnen würden also nichts bekommen oder sogar drauf bezahlen müssen.

Das Programmieren der Arbeitszeit-App ist ein klassischer Fall für eine öffentliche Dienstleistung, allerdings würden wir momentan für unsere Arbeit kein Arbeitsgeld erhalten, selbst wenn wir einen gemeinsamen Betrieb erstellen, einen Plan für das Programmieren der App erstellen und darin unsere Arbeitszeit angeben würden. Eben weil es momentan keine produktiven Betriebe in der App gibt.

[sloschert]

Noch ein Zusatz: Öffentliche Dienstleistungen und öffentliche Produkte, die ja kostenfrei abgegeben werden, dürfen ausschließlich Konsumprodukte für den Endverbrauch sein, dürfen also nicht von Betrieben als Produktionsmittel oder Rohstoffe erworben werden.

Dies aus dem Grund, damit die Preise der produktiven Produkte tatsächlich die in ihnen steckende Arbeitszeit ausdrücken.

Umsetzung:

• Einschränkung des Erwerbs öffentlicher Dienstleistungen in den Use Cases "pay_means_of_production" und "PurchaseProduct".

[seppeljordan]

Ich habe mir den Issue gruendlich durchgelesen und finde es verstaendlich.

[sloschert]

Super, leider muss ich nochmal etwas ausholen, weil die Implementierung der öffentlichen Pläne weitergehende Änderungen notwendig macht, um zu verhindern, dass ArbeiterInnen unterschiedliche "Stundenlöhne" bekommen, nur weil ihr Betrieb zu unterschiedlichen Zeiten seinen Plan eingereicht hat.

(Negativ-Szenario: Dienstag: Betrieb A reicht seinen 1-Jahres-Plan ein. Der Auszahlungsfaktor beträgt 1, da es keine öffentlichen Betriebe gibt. Die Beschäftigten erhalten den vollen Lohn für das ganze Jahr upfront. Mittwoch: Der öffentliche Betrieb B reicht seinen Plan ein. Donnerstag: Betrieb C reicht seinen Plan ein. Der Auszahlungsfaktor beträgt nur noch 0,5. Die Beschäftigten von Betrieb C bekommen nur die Hälfte ihrer Stunden bezahlt. -> Nur Betrieb C finanziert den öffentlichen Betrieb, von dem aber alle Betriebe profitieren.)

Die folgenden Gegenmaßnahmen sind nötig:

a) Es gibt fixe Termine (z.B. täglich um 10 Uhr morgens), an denen neu eingreichte Pläne aktiviert werden, abgelaufene Pläne deaktiviert werden und Credit gewährt wird. Eingereichte Pläne werden also nicht mehr umgehend nach Einreichung aktiviert, sondern erst zum nächsten Termin. Genehmigung oder Ablehnung der Pläne kann wie bisher unmittelbar nach Einreichung geschehen.
b) Um 10 Uhr gibt es also eine Übersicht über alle aktiven Pläne, aus denen nun der tagesaktuelle Auszahlungsfaktor berechnet werden kann. c) Betriebe erhalten ihre Arbeitszertifikate nicht mehr im Voraus für den ganzen Plan-Zeitraum, sondern täglich, nachdem der Auszahlungsfaktor berechnet wurde.

Anmerkungen:

• Der fixe Termin sollte genau einmal pro Tag stattfinden, weil der kleinste mögliche Planungszeitraum 1 Tag beträgt.
• Ob der Betrieb die Arbeitszertifikate täglich an die Belegschaft weitergibt oder z.B. wöchentlich, ist Sache des Betriebs.

Umsetzung:

• Neue Plan-Attribute is_active.
• Modifizierung des Use Cases calculate_plan_expiration_and_check_if_expired() (keine stundengenaue Berechnung mehr notwendig)
• Cron-job, Heroku-Scheduler o.ä. serverseitig, der täglich einmal folgende Funktionen ausführt: 1) Aktivierung neuer, genehmigter Pläne (falls nötig). 2) Deaktivierung von Plänen, deren timeframe abgelaufen ist. (falls nötig) 3) Genehmigung des Kredits für Produktionsmittel für die neuen Pläne. (falls nötig) 4) Berechnung des tagesaktuellen Auszahlungsfaktors. 5) Auszahlung der Arbeitszertifikate für alle aktiven Pläne.

@seppeljordan @mi01 Spricht aus eurer Sicht etwas gegen die Einrichtung eines entsprechenden serverseitigen cron-jobs? Oder gibt es bessere Möglichkeiten, so ein event zu triggern?

[seppeljordan]

Die Tatsache, dass die Genehmigung der Plaene durch einen cronjob getriggert wird, sollte als Implementationsdetail behandelt werden. Der use-case selbst sollte also nichts darueber wissen, dass "er ein cronjob ist". Man koennte sogar einen Schritt weiter gehen und den use case so implementieren, dass er beliebig oft ausgefuehrt werden kann, ohne dass sich das negativ auf das gewuenschte Verhalten auswirkt, z.B. in dem geschaut wird, welche Plaene ueberhaupt in Frage kommen und nur diese beruecksichtigt werden. Dann waere es egal, ob der use case erst um 10:30 ausgefuehrt wird, es wuerden nur Plaene beruecksichtigt werden, die vor 10 Uhr eingereicht waren.

Um deine Frage also zu beantworten: Meiner Meinung nach spricht nichts gegen einen crobjob.

[sloschert]

Kurzes Update: Ich hoffe heute oder morgen einen PR zu diesem Issue zu veröffentlichen. Wird ein etwas größerer PR.

[sloschert]

Habe jetzt auch den cronjob (Heroku Scheduler) eingerichtet. Müsste jeden Tag um 8 a.m. UTC die synchronisierte Planaktivierung triggern.

Es gab leider nicht die Möglichkeit, MESZ auszuwählen. Aber ewig werden wir ja vermutlich nicht auf Heroku bleiben, von daher denke ich dass es erstmal ok ist.