Maintaining a wiki is a cluster.
It can be super frustrating because you end up with a lot of empty linksā¦
Idk if this is standard, but the Open Source Ecology wiki was set up so that if you searched a page and it didnāt exist one was created. IF the wiki is clean and usable it is invaluable.
I donāt know anything about Git pages. That may be a better solution.
People know what a wiki is, though, and there shouldnāt be an intimidation factor.
Even some developers I know are shy of GitHub (surprised thingy), and not because Microsoft bought it.
Documentation is ESSENTIAL to the success of a project, especially this early documentation. Ten years from now this is where the payoff will showā¦ what we put into documenting now will save time and repeated efforts later.
I like the idea of using SourceCred and pollen for this.
2 to 3 Honey is nothing for a team to build a wiki.
*speaking as someone who tried to clean up dead links and maintain order on a project wiki for a couple of years.
So reading back through the comments, there are wiki formats that have pull requests so that people can propose edits officially but without having access to actually change the documentation?
That sounds like a very good feature.
yes, that is correct. Anyone can fork>clone the code and submit a PR. Then the reviewers would be the only ones who can merge the code. All parties would get cred so this incentivizes updates to the wiki.
I canāt reiterate the above enough. I have personally been through over 150 companies covering the small, medium and into the fortune1000 class type company cap valuations. I am familar with ISO standards and application of ISO requirements to systems and in my own experience doing so on the face appears straightforward. In practice ISO implementation requires a huge amount of overhead NOT justified or justifyable in smaller organizations. This isnāt just about following an laid out implementation metric (ISO is good for this) but getting and being ISO certified (which is usually the goal in any organization using ISO). Total overkill for smaller organizations with little to no real reward.
I completely agree with @s_ben regarding price other than I didnāt vote for this because I believed it was too ambitious and didnāt have clearly defined, quickly achievable steps, including time frames for step completion as well as a maintenance budget. My biggest issue with 1Hive is the lack of being able to do something long term. Example you ask for 13HNY and want this as a one-off to get it going (or for work done?) but the number picked is rather arbitrary. What if HNY is worth $40 tomorrow? This still going to work? Also there is no long term maintenance component. Iād personally vote for 20HNY if say 4 was for upfront work (say 1/4 man month) to lay everything out in detail in the 2-4 weeks and then 4 more to start implementation (2-4 weeks) and like 1 HNY/month for maintenance of what was being built. Is this enough to get going and commit for 1 year worth of maintenance, maybe not. But really I want to see a proposal like this in $$ vs. HNY (which is being worked on discussed) and with some kind of longer vision and a budget that can pass conviction voting.
I am agnostic to Tools except to point out everything in a startup is about capital efficiency and using a system that has lowest barrier to entry and highest productivity (bang for buck)
I completely agree with this and want to echo this should be an important consideration when setting up such a system.
I 100% agree. @s_ben also going to give you a heads up. I think my 30 years of personal work on solving the work-rewards issue and coupling my new model here with governance generally is yielding a solution/class that may lead to a major technology and implementation leap in SourceCred tech soon. I expect it will cover the vast majority of issues SourceCred and every work-reward type tokenomic systems are encountering. Once I finish writing up my model, I may need feedback and implementation help. Right now I am taking the ideas, merging them into a comprehensive model. Once I am done with that, I will simplify the whitepaper outline into a implementation specification as much as possible to get to the absolute bare bones needed to code and test a potential major SourceCred code fork/upgrade.
I believe my work will have a comprehensive solution covering all of the above. I am glad to hear you are finding generally in some cases sourceCred converging on ground truth as it is one of the reasons I see real value in sourceCred generally. For the most part SourceCred is converging on a result, that accurately reflects reality. It is my hope that my own work/contribution might help improve convergence, and reduce dramatically gaming components with additional tools with managable incentive/disincentive mechanics/structures/money/token/data/flows.
Echo the same observations as one who does have 10-15 years experience going through 150+ companies of varying sizes fixing some of the most difficult problems. There is a vast difference between the idealogical goals, and practical implementations. I have seen different companies granted various ISO statuses that on closer examination of their practices (by having to work within them even if for a short time) found that even ISO certified companies didnāt always follow ALL the ISO rules - even if for an ISO auditor - at the time of audit looked like they were. My on-site roles were vastly different in scope so it was not my place or job to comment. I simply noted and observed because I would get a completely different view of the guts of a company in terms of practical application (success or failure) than any auditor would ever see.
Btw I think we can use GitBook. Aragon use it and apparently they get it for free for being open source so we should be able too as well. Also it can be set up to be edited from Github. See the Aragon docs here with a link top right enabling a user to edit via Github: https://connect.aragon.org/ and it looks like itāll be really easy to edit. No need for any web dev knowledge, just Github markdown I believe.
Thanks for keeping us in the loop. @willjgriff, I get a 404 error on those links. Are you making these public? I would like to start playing with them when here back from them.
Anyone is welcome to message me on Discord if you want write access to update the wiki directly without going through Github. However, if anyone is interested in changing the structure please chat with me first.
Maybe this was already said but it appears Gitbook allows users to edit in Gitbook and merge from Gitbook. What is not clear is how this is done and if cred will be given for the ādraftā and āmergeā in Gitbook. Draft looks to be like a commit.
Nah there wonāt be any cred for editing using the Gitbook interface. Gotta edit using Github if you want cred.
EDIT: Actually I think there could be cred, depending on how the bot is set up and if youāre logged in using your Github account. Although it should probably be turned off because I made like 40 commits doing very littleā¦
Iād like to reiterate that we shouldnāt insist everything around here earns cred. If we want to make cred inclusive we should first focus on enabling designers and marketers platforms so they can earn cred as well as developers.
I was trying to find a good workflow and set of tools where designers could earn cred for their workā¦ unfortunately it kind of fell flat. Designers would have to use something like Abstract instead of Figma, since it has a version control system.
Iāve been told that the creditor essentially is the miracle solution for all these things, but Iām a bit skeptical, since the creditor basically turns this into a governance problem rather than an automated value discovery problem that plugins can do.
Iām good with turning off gitbook to sc. this would give us a back door to make small changes to not abuse cred. Short term the auditors would manage abuser who do a PR for 1 punctuation. Long term I think we could just apply plugins and weight the wiki really low relative to backend repos. There will probably always be a personal element