Parsed from META key comment
using pattern #n:
segments. Showing how many PB files share each comment.
Comment | # files |
Files
|
---|---|---|
This instance has not been fully validated | 116 |
|
The metadata regarding the age of voters shows very low values (starting from zero), indicating that one doesn't need to be an adult to vote: If a voter is under 13, they can vote with the consent of a parent or guardian. Hence, for example, age 0 likely corresponds to cases where parents/guardians are voting on behalf of their children | 113 |
|
The rule is unknown, however, it was most likely a greedy rule | 100 |
|
If a given project has multiple coordinates, then the average over these coordinates is taken | 82 |
|
The GreedySort works as follows: At the beginning, we sort projects based on the number of votes. Then, we fund projects that received the highest number of votes until the next project on the list does not fit within the budget. Finally, if the remaining budget is enough to fund at least 80% of that project, we fund it as well with the external reserve funds (for example, the unused funds remaining in other districts). We mark such project with number 2 in the selected column | 58 |
|
Sometimes, additional funds (for example, unused funds from other districts) are allocated to a district. These funds are used to finance the highest-voted projects that have not yet been selected. We mark such projects with number 3 in the selected column | 30 |
|
The leftover_budget entry indicates how leftover budget is spent | 30 |
|
Due to a voting system glitch, eight voters cast ballots for projects from the same category (e.g., two large projects in their district), violating regulations. To align with city-wide results, we tagged these voters with the prefix 999999 and separated their ballots into two distinct votes. The final election outcome was not affected | 29 |
|
This is not the original data. Some voters (around 0.5%) were removed due to the ambiguity | 21 |
|
Due to a voting system glitch, twelve voters mistakenly cast ballots for projects in two different districts, violating regulations. To align with city-wide results, we tagged these voters with the prefix 999999 and separated their ballots into two distinct votes. The final election outcome was not affected | 18 |
|
If unused funds remain in any district, they are aggregated and allocated to those unfunded projects with the highest number of votes. This allocation process may potentially violate the first-stage allocation rules (e.g., by exceeding the corresponding district budget), so we mark the projects funded at this stage with `2` or `3` in the `selected` column in the PROJECTS section. This signifies that they have been selected for funding, albeit at a subsequent stage of voting | 13 |
|
The budget_per_category is an upper bound on the sum cost of projects within a category selected by the voting rule | 5 |
|
The min_project_cost is a requirement on projects to have some minimum cost | 4 |
|
Due to regulations mandating a minimum of 50 votes for funding, some projects were not selected even though there was some money left | 3 |
|
The max_sum_cost_per_category is an upper bound per vote on the sum cost of approved projects within each category. It is unclear whether the voting rule is also required to respect this budget per category | 3 |
|
All internet votes and all paper votes were weighted such that both groups accounted for 50% of the outcome. No data is available on which voting method was used per vote | 2 |
|
Due to a system error, project 285 was mistakenly categorized as a citywide before being accurately reclassified as a local one. However, during this time, it had gathered 141 votes, making it appear as though some voters had cast two votes for local projects. We separated them by adding the prefix 99999 to the voter_id, to be consistent with city results and to avoid having incorrect (i.e., too long) votes | 2 |
|
Due to an error in the voting system, there were 4 voters with two local votes instead of one citywide and one local. The city counted them, so for the consistency of the results, we moved these four votes from the citywide to the local (added at the end with the prefix 11) and counted them as proper votes | 2 |
|
Projects funded by leftover budget are not constrained by the budget_per_category | 2 |
|
The max_sum_cost_per_category is an upper bound per vote on the sum cost of approved projects within each category | 2 |
|
The min_project_cost is a requirement on projects to have some minimum cost. 5#: The leftover_budget entry indicates how leftover budget is spent | 2 |
|
If there are unused funds remaining in any district or the citywide budget, they are aggregated and allocated to the district with the highest turnout. Therefore, we adjusted the budget from 194 431 to 236 277 | 1 |
|
If there are unused funds remaining in any district or the citywide budget, they are aggregated and allocated to the district with the highest turnout. Therefore, we adjusted the budget from 204 307 to 371 000 | 1 |
|
Initially, the budget for the citywide projects was set at 7,000,000. However, due to regulations, unused funds from district PBs were reallocated to citywide projects. Consequently, the citywide budget was increased to 7,605,325 | 1 |
|
Initially, the budget for the citywide projects was set at 9,000,000. However, due to regulations, unused funds from district PBs were reallocated to citywide projects. Consequently, the citywide budget was increased to 9,632,750 | 1 |
|
It happens that two (or more) projects are mutually exclusive, meaning they are intended to be implemented in the very same location. Therefore, the results presented in the ‘selected’ column may differ from those obtained by simply applying the greedy rule | 1 |
|
Project 586 was free (cost 0). To keep data consistent and not to have 0-cost projects (may cause problems when processing data) we set its cost to an artificial value of 1 | 1 |
|
Project BO.D18.9/23 was withdrawn after the voting due to a cost mistake made by the project proposer, who wrote '325' instead of '325000'. In the file, we changed it to an artificial cost of '999999999' | 1 |
|
Projects 42195 and 42190 had no cost specified in the original data: they were free (cost 0). To keep data consistent and not to have 0-cost projects (may cause problems when processing data) we set their costs to an artificial value of 1 | 1 |
|
The budget_per_neighbourhood is an upper bound on the sum cost of projects within a neighbourhood selected by the voting rule | 1 |
|
The cost of Project 237 was exceeding the district budget (546 000), which should not have happened. Unfortunately, it was eligible to be voted on | 1 |
|
The cost of the project W193ST (785,700) was exceeding the district budget (612,000), which should not have happened. Unfortunately, it was eligible to be voted on | 1 |
|
The leftover_budget entry indicates how leftover budget is spent. The leftover budget was supplemented by additional municipal funds to fully fund the extra project | 1 |
|
The max_length_per_category is an upper bound per vote on number of approved projects within each category | 1 |
|
The max_project_cost is a requirement on projects to have some maximum cost | 1 |
|
There is a difference between the number of votes in the file (222) and the official results (223) for project 1242. Since the discrepancy concerns only one vote and the city could not identify the root cause, we kept the number from the file (222) to maintain internal consistency | 1 |
|
Two plans tied for the last project to be funded. Additional municipal funds were used to fund both projects | 1 |
|
Voter 18546706357 voted only for two projects (44405,44417) instead of three, therefore this vote was deleted to be consistent with vote length (min 3) | 1 |
|
Young people between the ages of 12 and 27 could vote | 1 |
|