Giter Site home page Giter Site logo

madrypiotr / sdd Goto Github PK

View Code? Open in Web Editor NEW
3.0 4.0 1.0 7.69 MB

The Deliberative-Decision System. A tool of heterarchic management by ALL

Home Page: https://sdd.ha.pl

License: Other

JavaScript 26.33% HTML 73.12% CSS 0.40% Shell 0.01% Less 0.01% Stylus 0.01% Handlebars 0.12%
heterarchy community management social-system sdd management-program voting-system voting-application voting-app referendum

sdd's Introduction

The documentation of the SDD code is here or Go to CHANGELOG | LICENSE | CONTRIBUTING | CODE OF CONDUCT

About SDD

This system is designed to make it possible for everyone in the community to influence it. The principle of equal access to the conclusion, reconciliation and vote of ideas, proposals and projects is equal. There will be no admin system that can arbitrarily change anything, correct parameters, add users, restrict their rights, or delete. Any individual parameters and global settings, mode or mode of operation of the System are determined only by decision of all members. This procedure applies both to the startup of the System configuration and to changes made during further use.


THIS IS A WORKING WERSION OF THE SOFTWARE. IT CAN NOT BE PUT INTO PUBLIC SERVICE!


Here's how it works today: SDD

Applied technologies: METEOR, MongoDB, HTML5, NodeJS, jQuery, Bootstrap.

Installation

Run

  • meteor npm install
  • meteor run

OR

  • npm install
  • npm run

Tests

  • npm run test

SDD does not have an admin panel. All settings are done according to the will of all users

How to contribute to the development of this project?

The task of the application will be:

  1. accept requests for new users,
  2. accept User requests on various matters,
  3. enable discussion of reported cases,
  4. give priority to those matters in accordance with the will of the users,
  5. submit the three highest rated cases to the vote,
  6. handle voting,
  7. transfer win the issue to the panel Realization and generating a Resolution,
  8. ensure that the issue is addressed,
  9. in the absence of the implementation report - alert the Users,
  10. when the issue is not implemented and lack of implementation reports - throw it in the trash.

These are the most important operations that are already implanted. However, our application is similar to your home in the raw state. We still have to do finishing work and usability.

Important but simple - in SDD the basic objects are Issues (added by users). Then the issues pass the Deliberation / Voting / Execution path. The above listed operations will be implemented in five main panels (see illustration).

So ... what these panels do:

Panel / STATUS a description of the action
KWESTIA_STATUS.DELIBEROWANA Here you will get every idea, proposal, problem to solve. We call it the Issue.
It has many statuses. On startup it is set to active as "deliberate". Issues receive priority points from users (-5 to +5). They are on the list arranged according to the values of the sum of priorities. Issues with the highest priority go to the next panel - Voting.
But priority, it's not just one condition. Conditions are three. In addition to the priority, three more people need care for the issue (Implementation Team), and the appropriate quorum (in accordance with the organization's regulations). The Issues remain here until they reach the required conditions for Voting.
KWESTIA_STATUS.GLOSOWANA The Issues that have entered here will be voted for by the time set in the system's global parameters. At this time there is no deliberation, only vote. Hence, Issues can land in three places:
1. in the Trash, if the Issue does not get a positive sum of the parameter,
2. in Hibernation, if there were Issue-Option, but did not win the Voting,
3. in Implementation (next panel), if she won the Voting.

a. KWESTIA_STATUS.REALIZOWANA
b. KWESTIA_STATUS.ZREALIZOWANA
The panel Implementation is divided into two subpanels: Realized and Executed.
a. Realized. The Issues are being implemented as long as their priority is positive. The Issue may also be thrown into the trash bin by a user decision.
b. Executed. The Issue may be decided by the users considered completed. Then lands in this panel.

a. KWESTIA_STATUS.TRASHBIN
b. KWESTIA_STATUS.HIBERNOWANA
The panel Archives is divided into two subpanels: Thrash bin and Hibernating.
a. Thrash bin. Here are the issues that were thrown out by the users decision. Also, those Issues that did not work well in the implementation, that is - their priority dropped below zero - fall into the Trash.
b. Hibernating. In the Hibernate panel are placed specific issues. They jump right here from Deliberation. When out of many Question-Options, one of them wins the vote - the other is being put into Hibernation. It is obvious that only one of the Options can be implemented. Only if this winning issue has been withdrawn from implementation - The hibernated Issues are defrosted and return to Deliberation.
KWESTIA_STATUS.ADMINISTROWANA This status is given to Issues whose status has not yet been assigned. For example, the issue of changing a global parameter or Personality when a new user is assumed.

See all TIMELINE - SVG


(c) 2013-2017, PM & Partners. All rights reserved.

sdd's People

Contributors

madrypiotr avatar michalw avatar

Stargazers

 avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar

Forkers

deliberarchia

sdd's Issues

Edytor plików JSON, czyli ostateczna eliminacja funkcji admina

Pozostałą jeszcze adminowi operację na językach, również trzeba wzbogacić o tłumaczenie przez użytkowników-tłumaczy.

  1. tłumaczenie serwisu (zakończone generowaniem regionalnego pliku JSON), a w przypadku istniejacego - aktualizowanie.
  2. edycja istniejącego pliku JSON w tym samym trybie (tłumaczenia),
  3. aktywowanie / dezaktywowanie języków dla wyboru przez użytkowników.

Docelowo logowania admina nie będzie (będzie nazwane logowaniem tłumacza).

Zachowanie akapitów

W trzech miejscach:

  • szczegółowy opis Kwestii,
  • komentarz,
  • odniesienie do komentarza,

trzeba zapamiętać znaki nowego wiersza, aby piszący akapitami miał je zachowane w widoku.
Obecnie, pisany tekst (np, jak powyższy) widziany jest przez użytkownika tak:

W trzech miejscach: - szczegółowy opis Kwestii, - komentarz, - odniesienie do komentarza, trzeba zapamiętać znaki nowego wiersza, aby piszący akapitami miał je zachowane w widoku.

Jest to mało przyjazne w czytaniu,

SSR.render

Ukończenie rozpoczętej przebudowy mechanizmu SSR.render.
Powiadomienia e-mail wychodzą wadliwe.

Listy do aplikującego nowego użytkownika.

Pierwszy list

  1. W nagłówku listu ma być:
    Potwierdzamy wpływ aplikacji o przyjęcie jako Członka
  2. W treści ma być:
    SDD
    { org_name }
    Szanowny { Imię Nazwisko }!

Do systemu: SDD - { org_name } wpłynęła Twoja aplikacja o przyjęcie.
Trwa głosowanie.
Po jego zakończeniu otrzymasz drugi list z danymi do logowania.
Dziękujemy!

--
Jest to automatyczna informacja z systemu SDD - { org_name }
Nie odpowiadaj na nią.
.
pierwszy list do aplikujacego

Nie można Dołączyć.

Najpierw sprawdzić, czy może ta funkcja nie może pracować na localhost, gdzie testuję? Może na serwerze zdalnym zadziała?

  • Pierwszych 5-ciu użytkowników wprost rejestruje się - (działa).
  • Od tej pory System przestawia się w tryb aplikowania - (działa).
  • Teraz System oferuje przycisk [Dołącz], który angażuje m. inn.:
    SDD\client\views\account\czlonek_zwyczajny_form.html
    SDD\client\views\account\czlonek_zwyczajny_form.js
    SDD\client\helpers\methods_users.js

... niestety - po prawidłowym wypełnieniu formularza, kliknięcie submit'a [Aplikuję o przyjęcie]
nie powoduje poprawnej akcji dodania w Systemie Kwestii Specjalnej w kategorii "Osobowa".
addIssueOsobowa, lub addKwestiaOsobowa
Formularz nie znika, chociaż ponowna próba aplikowania z tym samym e-mail'em kończy się komunikatem, że już jest w bazie taki użytkownik. Został poprawnie wpisany do bazy oczekujących w kolekcji usersDraft.
Nie pojawia się on jednak na wykazie Użytkowników, co jest prawidłowe, ponieważ najpierw powinien się pojawić jako Kwestia Osobowa na wykazie Kwestii do zatwierdzenia przez Ogół w głosowaniu.
.
Ta procedura wcześniej działała poprawnie.
Na http://www.syncodec.net działa (nie opanowałem jeszcze deploy na NodeJS). Może prace rozwojowe na localhost spowodowały gdzieś wprowadzenie jakiegoś błędu lub usunięcia istotnego fragmentu,

Odmowa przyjęcia (odrzucenie w głosowaniu)

Testowalismy opcję nieprzyjęcia aplikującego.
CRON nie wie co zrobić z Kwestią w przypadku priorytetu 0 lub ujemnego w głosowaniu.
Powinien skierować Kwestię do Kosza.
Ta kwestia jest Kwestią aplikowania, więc aplikujący powinien otrzymać list
SDD\private\email_application_rejected.html
.
odmowa

Usterka 4 Powiadomienia e-mail

Do uporządkowania SSR.
Nie wszystkie e-mail'e (powiadomienia systemu) przychodzą kompletne.
Przykład poniżej.
ust_powiadomienie e-mail
.
Przykład prawidłowy z lutego br.
ust_powiadomienie e-mail luty

Usterki drobne ...

USTERKA 1. Pobranie języka.
W rejestracji już dobrze, ale w aplikowaniu bierze jeszcze z JSON-a ang.

e-polski

image

... i dalej się to za Aplikującym ciągnie ...
image

Język domyślny na start

Wszystko działa OK dopiero po wybraniu danego języka.
Na start, jak również po "ręcznym" przeładowaniu, klient widzi nazwy zmiennych (nawet ten zalogowany, który określił swój język w profilu).
Skoro użytkownik, klikając, otrzymuje pożądany efekt, to pewnie System "sam z siebie" będzie mógł to uczynić, trzeba mu to "powiedzieć" w kodzie.

Trzeba spowodować,

aby j.polski, który jest językiem domyślnym był faktycznie widziany "na dzień dobry".

Język domyślny jest zdefiowany w pliku: ... lib\constants.js

LANGUAGES = {
    DEFAULT_LANGUAGE: "pl"
}

Natomiast po zalogowaniu już tylko język Użytkownika.

Przekwalifikowanie Doradcy

Gdyby Doradca chciał zmienić swój status na Członka, trzeba opracować sposób prostszy, aniżeli aplikowanie "od zera".
Powinno to polegać na uzupełnieniu jedynie brakujących danych w stosunku do profilu Członka.
Oczywiście - w efekcie również powinna powstawać niczym nie różniąca się od innych - Kwestia aplikacyjna.

Place the [Relized] button

Place the [Relized] button in the details of the Issue, which is in the Implementation panel.
Result - creation of a special comment for placing Issue in the panel "Realized".
Tip:(procedure already developed for the [To Trash] function).

Priorytet po głosowaniu bez zmian.

Potrzebna drobna korekta ...
image

Po głosowaniu Kwestia powinna zachować wielkość priorytetu i startować w realizacji z priorytetem, jaki miała na koniec głosowania.

Przydzielać Kwestię Osobową od pierwszego rejestrującego się.

Opis wstępny

Użytkownicy od 1-go do 5-go w prosty sposób rejestrują się w Systemie.
Następni Użytkownicy są już przyjmowani do Systemu w trybie aplikowania.
Aplikowanie kolejnych (od 6-go) Użytkowników generuje im Kwestie Osobowe, które są procedowane tak samo, jak każda inna Kwestia, czyli po przegłosowaniu staje się Kwestią w realizacji. Dopóki trwa realizacja Kwestii Osobowej, Osoba jest Członkiem Organizacji.
Takie procedury są celowe i zamierzone w projekcie.

Problem

Otóż, pierwszym 5. Użytkownikom System nie generuje Kwestii Osobowych. W wyniku tego są oni de facto "wyjęci spod prawa". Nie można ich oceniać ani (ewentualnie) - rozstać się z nimi.

UWAGA

Należy zachować funkcję tworzenia na starcie Systemu Zespołu Realizacyjnego ds. Osobowych i przydzielanie do jej składu sukcesywnie trzech pierwszych rejestrujących się Użytkowników.

Sprawdzać this.userId

@MichalW proponuje:
Pozwolę sobie jeszcze zwrócić uwagę na Pana niezabezpieczone metody serwerowe:
Każdy (nawet niezalogowany) użytkownik może wykonać metodę np.:

Meteor.call('removeZespolRealizacyjnyDraft', {});
co spowoduje usunięcie pana dokumentów z bazy danych.
Należałoby sprawdzać this.userId.

Operacja usuwania użytkownika (również swojego członkostwa).

TO BARDZO PROSTE i z wykorzystaniem już istniejącego kodu nazwanego "[Do Kosza]" (UWAGA: zmieniłem wizualnie na "Do Archiwum", aby ludzi nie wyrzucać do kosza :) )
Bo też Kwestia Osobowa ma działać, jak każda inna Kwestia, a więc wyrzucenie "Do Archiwum" Kwestii Osobowej powinno równać się pożegnaniu się z użytkownikiem.
.
Póki co, w przypadku Kwestii Osobowej działa tak:

image

A więc znowu mamy okazję z tego alertu zrobić użytek i zamienić go na:
"Czy na pewno chcesz zaproponować usunięcie ... "
a) wersja dla Kwestii Osobowej: "... tego Użytkownika?
"
b) wersja dla innych Kwestii: "... tej Kwestii?_"
[TAK] [NIE]
A dalej już dotychczasową ścieżką - tworzenie Komentarza specjalnego dla decyzji ogółu ...

image

Powyższa treść już jest zmieniona w plikach JSON, aby odpowiadały nowej sytuacji.

Aplikowanie na nowego użytkownika - usterka.

Nie ukazują się szczegóły Kwestii aplikacyjnej.

  • W kolekcji "usersDraft" - jest
  • Na liście Kwestii - jest,
  • Po kliknięciu w nazwę Kwestii - nie jest prezentowana w szczegółach Kwestii.

50 || (wykonane) New line characters in textarea

There are no need for text editors (CKE or TinyMCE type) in the textarea fields, but it is necessary that the ONLY format of the new line is kept when the editor will enter it.
Without new lines and paragraphs, larger content is not very legible and looks very unprofessional.

PL

Nie są potrzebne edytory tekstowe (typu CKE lub TinyMCE) w polach textarea, ale konieczne jest aby był zachowany TYLKO format nowej linii, kiedy tak wpisze edytujący.
Bez nowych linii i akapitów większe treści są mało czytelne i wygladają bardzo nieprofesjonalnie.

Usterka 2 Regulamin

Nie pamięta treści Regulaminu pomimo poprawnego zrealizowania Kwestii specjalnej (parametru globalnego
ust_nie pamieta regul
)

Mieszanie języków (listy)

Te usterki ciągną się od dawna. Niewłaściwe pobieranie zestawu JSONa
W przypadku przyjmowania nowego funkcją [Dołącz] (Aplikowanie).
.
1 list - info o wpływie aplikacji - PO POLSKU (prawidłowo)
1
.
2 list - wezwanie do walidacji - PO ANGIELSKU (NIEprawidłowo)
2
.
3 list - podanie danych logowania - PO ANGIELSKU (NIEprawidłowo)
3

List - potwierdzenie wpływu wniosku.

Istniejące w templatce zmienne, nie wchodzą do listu. Najpierw oznaczyłem templatkę (5), aby mieć pewność, że to ona tu pracuje. Okazało się, że ona.
Wobec tego domyślam się, że nadal problemy leżą po stronie tych SSR.
Problem ten występuje jeszcze w kilku listach. Kiedy rozwiążemy problem tego - wskażę kolejne po testach.

Uwaga do ilustracji:
Oznaczone 1 - brak napisu w liście e-mail
Oznaczone 2 - też brak napisu w liście e-mail, ale to ostatecznie usunę, bo aplikujący w tym momencie jest dopiero w bazie, jako "Draft", a więc i tak się nie zaloguje, nie mając zresztą danych do logowania.
list - potw wplywu wniosku

Doradca - wyłączenie funkcji

Doradcy należy uniemożliwić operowanie na priorytetach.
Przykład: priorytetowanie Kwestii - już nie ma dostepu
Podobnie należy wyłączyć jemu możliwość prorytetowania komentarzy i odwołań.
Nie może też inicjować komentarzy specjalnych, jak [Do Kosza] (już nie może), ale nowo dodany [Zrealizowana] (może) - trzeba jemu wyłączyć.
.
Doradca może:

  • dodawać komentarze (dzdiała),
  • dodawać odniesienia do komentarzy (dzdiała).

doradca1 do kosza
doradca1 zrealizowana

Przy okazji ...
Niech button ma kolor tła taki jak jego komentarz specjalny.

button zrealizowana

Aplikowanie / Członek

Z chwilą przejścia z głosowania do realizacji, a więc nadania Kwestii osobowej statusu "realizowana",
należy jednocześnie zamienić przedrostek "Aplikowanie" na:

  1. w przypadku Członka - "Członek" - i18n --> {{glob.Member}}.
  2. w przypadku Doradcy - "Doradca" - i18n --> {{glob.Advisor}}.

aplikowanie na czlonek

Czyszczenie kodu z funkcji admina

Po definitywnej rezygnacji z ingerencji admina w sprawy merytoryczno-organizacyjne, z kodu mależy usunąć wszelkie zależności (bloki kodu zawarte w if) odnoszące się do ewentualnego zalogowanego admina, a także całe szablony, które miały adminowi służyć.

Advisors Engagement Panel.

We still lack functionality that will take advantage of the Registered Advisors.
You need to implement a mechanism to "pin" them to specific Issues already at the stage of deliberation. Of course, they should also accompany her during the implementation phase.
Members of the Implementation Teams will have professional help in this way. They should be able to recruit Advisers by nominating candidates for Advisers to register with the SDD at once with the assignment to a particular Issue at each stage.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.