Replies: 11 comments 1 reply
-
Yeah I agree with you , on the choose of the structure (number one) . One possible way to circumvent the issue is specifically telling the ones that do work on a remote basis. For example: Country A
Country B
*** Coops that do work on a a remote basis as well ! Of course the symbol can be changed for example a world emoji don't know : ) Btw: Maybe mark the ones that are currently wiring or open to applicants ! |
Beta Was this translation helpful? Give feedback.
-
One additional point of interest would be to provide the legal documents some of these companies use to form and govern their respective cooperatives. If you have any already, wouls be greatly appreciated if you could add some. |
Beta Was this translation helpful? Give feedback.
-
Just FYI guys, this repo could have github discussions enabled in order to help facilitate discussions like this: |
Beta Was this translation helpful? Give feedback.
-
|
Beta Was this translation helpful? Give feedback.
-
@motorto Thats a great suggestion! I think we should do it that way sort by regions/countries and add a note for remote coops. @carlos-reynosa I've enabled discussions I hope to have a bit more time to get started on this in February, but of course you could also just start restructuring the table ;) |
Beta Was this translation helpful? Give feedback.
-
If you need co-maintainers then let's fire up that cooperation ❤️ |
Beta Was this translation helpful? Give feedback.
-
Breakdown by countries could be a good start. Makes me wonder if, in the long term and for maintainability reasons, it would make sense to have a separate .json/.md file per-coop, with some mandatory schema and a script that would generate a README.md from that + a template. (e.g did something simple like that for bzz/computing-history) Also, do you think it makes sense to go though and merge all open PRs first, before re-structuring? |
Beta Was this translation helpful? Give feedback.
-
I agree with @bzz , maybe a system that allows easy insertion / removal of coops instead of having one huge file. Maybe create separated files by country, instead of individual ones per coop. The merging of PRs is something that should be done before the cooperation starts (the ones that @hng think are okay to ), at least in my opinion. I would totality cooperate with this ! If you need any help with something say so ! |
Beta Was this translation helpful? Give feedback.
-
I agree that having entries in separate files is preferable. Otherwise we're headed into a constant merge conflict territory (see #78). An alternative to, or an additional measure on top of, putting all the disparate entries into the README.md would be generating a gh-pages hosted static site using the entries. This is trivial to set up, and I'd be happy to lend a hand. A more ambitious alternative/addition would be aiming to migrate this directory to use something like the murmurations protocol. That's a whole different ball of wax, of course, and orthogonal to this more immediate problem. But I thought worth mentioning :) |
Beta Was this translation helpful? Give feedback.
-
My suggestion would be to start off as some type of machine data format, maybe json. I think this will allow the project to use the org data in different ways, whether it be displaying a table within the README or even displaying a map for some other application. It still might be possible to have each org in one file that eventually gets built into one master file. I think this will allow the focus to be set on having a good set of fields for each organization first and a good process for org contribution. How the data is eventually formatted and presented would be a detail for later. For example Maybe: Maybe the process could be that:
Org 1 Org File - orgs/org-1.json{
"org-1":{
"name": "org 1",
"licence": "coop",
"location": "Los Angeles"
}
} Master Org File{
"org-1":{
"name": "org 1",
"licence": "coop",
"location": "Los Angeles"
},
"org-2":{
"name": "org 2",
"licence": "coop",
"location": "New York"
}
} |
Beta Was this translation helpful? Give feedback.
-
As a first start I have split the list of coops now up into different regions. Is it ok this way? This already brings some more questions:
|
Beta Was this translation helpful? Give feedback.
-
As interest in tech-coops seems to be growing and this list is getting more exposure in the last few weeks, e.g. it was referenced in a MIT press paper, I would like to put some work again into it.
The structure of this list has been mostly untouched. Especially the table/list of tech-coops could use some more structure, as it grows.
I see three options:
I think I would prefer 1), as it's the easiest and logical one.
It would also be nice to have a interactive website at some point that allows filtering of the list of tech-coops, but I also like to have the list as a simple markdown file in Github.
What do you think?
Beta Was this translation helpful? Give feedback.
All reactions