It does seem a variant on annotation. I'd commend to the poster my analysis of the network utility of such systems I developed after pondering on them for quite a few years (I was interacting with them in the 1990s): https://news.ycombinator.com/item?id=23576213
I commend that to the author in the spirit of learning about the space and thinking through the implications, because I believe people are more likely to solve problems when they understand what they are, and think through them, and don't just try to blunder past them with hope and moxie.
That post was written about generalized text annotation and I stand by it in that context.
However, as you deviate from the system being analyzed, the analysis becomes less appropriate. One of the problems generalized annotation systems have is that there are an arbitrary amount of textual comments that can be added to a page. That is what turns the popular pages into a unpleasant cacophony. The range of links is somewhat more restrained. Plus, links are just... links. Textual comments are arguing and flames and generally tiring on any popular page. (Though I'd watch out for people learning how to turn "links" into arguments.)
It is possible that a shared cross-linking system might work, but I'd strenuously suggest thinking very very hard before adding in any sort of inline "conversation" system. It is very, very obvious and very, very tempting... and it immediately puts you back into the generalized web annotation space, which is strewn with corpses, many of them very very well funded. You can have a "community forum" where people can talk, and perhaps even should, but putting it inline on the page is basically a known-fail. If you think you've got a solution to that I'd try to be very sure that you've got a very strong proposition on exactly how yours is different than the previous attempts.
Anyhow, I would just generally suggest to the author that this is one of those "obvious ideas" that hasn't happened because in general they flame out so quickly that you don't even find out they existed before they've already collapsed, not because nobody has ever tried it. Be sure to consider what has happened in the past.
Also, as a hint from previous efforts: It looks like you may be trying to bind links to specific text on the page. As you've probably already discovered, that's harder than it looks, and however much code you've written for it, I guarantee you it's even harder than that. I'd strongly suggest considering just binding links to pages and not trying to bind it to text at all.
I think generalized annotation has the following problem:
Draw a graph of all web pages ordered by how many times they are visited. You get a power law distribution. On the left are things like CNN's front page, on the right things like a text file containing a cheesecake recipe someone posted in 1995 that is technically still online but nobody has visited in years.
On the left side are pages that are visited too often, and public annotations inevitably descend into madness and chaos, even worse than comment sections which have the courtesy to at least be isolated on the page to a certain area. On these pages, trying to use the annotation software is worse than not using it at all.
On the right are the pages that nobody visits, so when you visit them, there is no chance of any annotations being on the page, nor any chance that if you leave any annotations anybody will ever see them, or care if they do (i.e., just giving people a directory of "rarely annotated pages" doesn't solve the problem, the problem is that nobody cares about these pages anyhow). Annotation software doesn't harm these pages technically, but the user experience is at best that the user will just forget about their annotation software, and at worst, they'll feel alone on the page, a concept not previously in their mental model and one that is not contributing to a positive assessment of the annotation software.
In between is the sweet spot, where participation is adequate that the annotation software brings some sort of value, but it isn't just overwhelming chaos.
I submit to you that viewed through the power law lens, that sweet spot is actually fairly narrow. Moreover, if you slice through a single user's browser history looking for when they hit pages in that sweet spot, it'll still be the minority of pages that they viewed, so basically by statistical necessity, the pages where the software added value must be a tiny minority of the pages you visit. The majority of pages they visit, the annotation software experience ranges from extremely net negative to at best neutral, and it's hard for the positive experiences to make up for that.
Moreover, this sweet spot is moving. As more of the general public tries out your software, the sweet spot moves to the right, which also has the effect when viewed from a single user's point of view of making the pages where it is useful become more rare. When you're just starting out and you've got a 100 users, the useful pages are things like "the front page of CNN" and "the hot wikipedia article about $CURRENT_EVENT", but as your user count increases it moves down to specific articles on CNN and only the linked content from the $CURRENT_EVENT, then only to archival content on CNN and random Wikipedia pages, and just in general into stuff that becomes increasingly difficult for it to be any significant percentage of the pages you visit.
I think this is why A: They can't get popular B: the ones that I know about that have been around for a while and are therefore presumably successful enough for someone to consider them worthwhile can only stay so provided they don't get more popular and C: there's no chance you can make money in this space because you get an anti-network effect... the more users you get, the less valuable the service becomes to every existing user!
I think this is also why it seems like such an appealing idea. You create a prototype, get a couple of friends on it, it seems like fun and to be useful. You annotate some popular pages, you have some similar interests and you annotate, I dunno, the latest game console announcement or something, and it seems like fun. The problem is, rather than this being the worst the experience will ever be as it just gets better and better as more people come online, this is the best it will ever be.
Also, I can tell you from the first couple of times around that if this did become popular, the content producers of the Internet would fight you tooth and nail. They did the first couple of times when the math sort of worked to at least get to the point that these things could get in the news. With the web so much larger and power-law-y and the anti-network effect correspondingly so much more powerful, now this sort of thing can't even be successful enough to so much as get noticed by anyone before it has already collapsed.
(I specifically said "generalized" annotation at the top, because specialized use cases can get around some of these issues. But it's going to be hard to make any money on the size of user base you can support, because while you can mitigate the anti-network effect, it's always going to be looming over you if you try to get large enough.)
It's (partially) a fundamental problem with Python and (all?) other popular programming languages. The majority of libraries don't need more authority than doing (some) computation, yet any Python script can access anything and everything by default.
The https://en.wikipedia.org/wiki/Principle_of_least_privilege as constructed by https://en.wikipedia.org/wiki/Capability-based_security is the solution for this, yet Python will probably never be capable of this kind of internal encapsulation, it's too much of a fundamental change - and even if some sort of sandboxing ability is accomplished, creating separate/recursive sandboxes (needed when importing more, separate libraries which in turn import libraries whose authority they want to limit) will probably require another interpreter instance for each sandbox (as with WebAssembly).
I hope current and future language designers will take this into account, and construct their compilers, virtual machines and interpreters accordingly. Python was created before the internet as we know it now existed, so perhaps its lack of security mechanisms shouldn't be surprising. But it and any new developments that fail to consider this aspect of computation will be fundamentally flawed from the beginning.
Funny thing though, I worked in ad-tech for ten years at a small player (outbrain). They're present on most major news sites around the world, which means I got to dig into the source of many of these sires. Easily 90% of their source was dedicated to serving ads or tracking behavior for campaigns. And we're talking a ton of code. It's like they're in an arms race with themselves where their site is an expensive nightmare to maintain so they add ads which makes their site an expensive nightmare so they add more ads.
I think there's a significant question about the linearity of the scale. Is this quadratic, linear, logarithmic, exponential?
If quadratic, then the Cheesecake Factory experience gives you 9 "utils" and Poppy gives you 100 utils. You'd rather eat at Poppy once a month than Cheesecake Factory 11 times a month, but you'd rather eat at Cheesecake factory 12 times a month than either. (If 12 times a month is too much, swap these for per-year numbers.)
If linear, then Cheesecake Factory gives you 3 utils and Poppy gives you 10. You'd rather eat at Poppy once a month than Cheesecake Factory 3 times a month, but you'd rather eat at Cheesecake Factory 4 times a month than either.
If logarithmic, it doesn't really matter what the base of the logarithm is. Suppose it's 10. Then Cheesecake Factory gives you 0.477 utils and Poppy gives you 1 util. You'd rather eat at Poppy once a month than Cheesecake Factory twice a month, but you'd rather eat at Cheesecake Factory three times a month. I think this is roughly how my restaurant scale works.
If exponential, it does matter what the base of the exponential is. Suppose it's 10. Then Cheesecake Factory gives you 1000 utils and Poppy gives you 10 billion utils. You'd rather eat at Poppy once in your life than Cheesecake Factory an unlimited number of times (once a week for 200,000 years). But if the base of the exponential is 2, then we're talking about 8 Cheesecake Factory utils versus 1024 Poppy utils. In that case you'd rather eat at Poppy once every 4 years than at Cheesecake Factory once a week, but you'd rather eat at Cheesecake Factory (or an equivalently good restaurant) once a week than at Poppy every 5 years.
So, how does that 1-10 scale map to your preferences?
I think we can stop recommending License and Contributors since GitLab is mostly used for closed source software. The templates will still be there but just not suggested until you started to create a new file.
And you should be able to disable everything but the repo if you want to. And of course you can disable the repo as well if you just want the planning features for example.
I'm the founder of a company that is ~250 people, remote first, and still fully remote. We do have an office in SF, but ~10% of our employees are present, almost no full teams are centralized, and all our processes revolve around remote work. Important to note that we're a US-founded company (this comes along later).
I'm going to use this comment as a way to talk about remote hiring generally, rather than respond directly to your comments. I want to help others understand some of the challenges it has been being one of the larger (relatively) fully distributed companies.
I think there is a common misconception that the world is mostly flat and that our company can hire from anywhere. I am commonly criticized when tweeting job postings (almost always remote) when the countries we can hire from is limited to a select few. "Not real remote" "first world remote only" "remote != 8 countries" etc. are common criticisms.
Disclaimer for the remainder: I am not a lawyer and my exact details because of that may be wrong. Please consult your own legal team.
When hiring remote, there are a few things to keep in mind:
1.) You have to adhere to employment laws within the country you're hiring from. Employment laws vary widely between countries and getting them wrong can be very expensive. For example: vacation time will vary, holidays will vary, the ability to let someone go will vary, what you can/cannot expect from an employee varies. In one country, emailing an employee outside of work hours is legally considered harassment; when working with multiple timezones that's a challenge because "in work hours" for one country may be "out of work hours" for another country.
2.) To employ someone full time, many countries require you to have a legally entity within that country. Establishing a legal entity takes a lot of time and a lot of money.
In the past 12 months, we've had at least one member (more now) on our HR/finance teams establishing legal entities _full time_. I've had my signature on at least 8 incorporation documents in the past 6 months. By the way, most incorporation documents require a "wet" signature so if you're remote like we are, be prepared to be FedExing a lot of sensitive legal documents around.
Beyond just paperwork, there are often requirements to establish a legal entity: a real, physical, local address is one. In one country, we had to pay out of a local bank account in local currency (which has its own red tape), and this country also required we maintain a minimum balance to pay 3 months salary in the local account in local currency at all times. For a startup, that much cash "not working" can be problematic depending what stage you're at.
In one country we're establishing an entity in, the process just takes a LONG time. We've been responding to any inquiries and sending paperwork immediately and we're 8 months in and still probably 2 months away from completing the process. Meanwhile, we still can't legally hire there.
A lot of legal paperwork is understandable in the local language of where you're creating the entity. This means that you also have to pay lawyers fluent in that language to vet the paperwork. We employ full time lawyers, but primarily in English, so this requires us to go to expensive outside counsel.
Finally, this is all expensive. There are fees to creating entities but also recall that we have multiple full time employees that spend their entire day establishing legal entities. So we have our own full time salary costs plus filing costs plus legal costs.
3.) Hiring contractors DOES work around some issues, but has its own downsides. First, we can't offer options/stock to contractors and we'd like all our employees to benefit from this. Second, we often can extend the same full time benefits we want all our employees to share such as healthcare, 401K, etc. Put another way: we want all HashiCorp employees to be employees, we don't want to create second class citizens.
Legally, some countries have legal limits on the hours a contractor can work or length of time they can be contracted before they're considered an "employee" by default and regardless of what you SAY the relationship is, the country will consider it employment and points 1 and 2 above all take effect immediately.
So we certainly DO hire contractors but our point of view is that we intend to hire those people full time over time. We'll often hire contractors if we know that we'll have a legal entity established to hire them within X months, and we're up front with the new hire about this. We'll also pro-rate option/stock vesting for their contractor period when they are hired.
4.) We prioritize countries where we have the most interest. We get asked a lot "please hire in X" but if the number of times we've heard X is much lower than Y, then we'll prioritize Y first.
This creates somewhat of an imbalance, since more countries with a more established tech ecosystem generally have more qualified candidates and therefore get prioritized higher.
We WANT to hire from everywhere, but as a startup with constrained capital and timelines, we have to be pragmatic about choosing the locations where we'll probably be able to hire the most roles while we continue to expand our entities.
5.) We are also open to relocating employees into countries where we do have entities. We've done this multiple times, we pay a relocation fee, and its a great way to hire someone from a country where we can't [yet]. Also note they're "relocating" but are still working remote.
Of course, this is highly dependent on the individual and it is unfair of us to ask or force someone to do this if they have an established family, friend circle, and generally just a life in their existing country. So this only works some of the time!
6.) Despite building process around remote-first, we try to a keep a healthy timezone overlap in each of our teams (3 to 4 hours out of the working day is best). We find that teams that have a team member with a non-overlapping TZ struggle for multiple reasons. So, even though we can hire in many countries now, we'll restrict some job postings to certain countries so we can have that overlap.
EDIT, some additions:
7.) Each US state ALSO requires a legal entity in addition to adhering to state-local employment laws, taxes, and more. At this point HashiCorp has entities in ~30 US states.
Further, there is a tax consequence to the business outside of employment taxes. If you hire an employee in a state, you also now have to pay sales tax on revenue from there. You may argue for/against whether that makes sense, but for a startup this can be VERY expensive.
Our corporate tax obligation would be hundreds of thousands of dollars [less] if we didn't employ people in New York state. We've had to weigh this in cases because the tax obligation from hiring _one_ individual could suddenly be that you can't afford to hire _multiple_ other individuals.
Note we don't want to avoid taxes, that's not what we're doing. But startups are capital constrained and we have to determine long term how we continue to grow and hundreds of thousands of dollars can make a difference.
Finally, I want to note that we're 100% dedicated at HashiCorp to remaining fully remote. We WANT to hire from everywhere. We're establishing the entities and process to hire in new countries full time. 18 months ago we could only legally hire in 2 countries, today we can hire in 8. By the end of the year it should be at least 4 more. We'll continue from there.
I could write a LOT more about culture and process within the company. But this comment is already getting very long and I think I'll keep it to this. Maybe in the future I'll write more about "chat literacy", the importance of decision inclusion, things that definitely don't work, keeping people motivated/happy, managing people you can't physically see, the lack of body language for signaling, and a lot more.
While I agree with your overall sentiment, the Levine book is not a good reference. Here's a comment I'd posted about the book in the past:
I would be wary of taking that book at its word. The authors have an agenda and they are not afraid to twist historical facts to suit their narrative. I mean, their very first chapter begins with a lie which perpetuates the myth that Watt's patent retarded steam development [1].
When the authors of [1] called out Boldrin and Levine on this, the latter responded by fabricating new myths rather than admit that the truth undermined their narrative [2].
The very chapter you cite itself has such inaccuracies. I did not track down all the stuff they cite, but I did find an instance of mischaracterizing references to suit their view points. For instance, when they discuss the German dyestuff industry, they cite a study by Murmann to support their narrative that Germany dominated in that industry due to the lack of patents. But if you look at the actual study itself, Murmann paints (heh) a very different picture: German dominance in that industry was fueled by close ties with academic research, and later by R&D labs encouraged by, of all things, the newly introduced patent laws:
>When in 1877 German patent law protected dye innovations, a few German firms such as Hoechst, BASF, and AGFA saw the advantage of hiring organic chemists whose sole task was to synthesize new dyes. After these research chemists turned out economically successful dyes, firms hired more and more chemists and pioneered an entirely new corporate function, formally organized research. The birth of corporate research and development (R&D), which today is a standard activity in high-tech industries ... can be traced to the German synthetic dye firms in 1880s. By the 1890s the vast majority of dyes were being discovered in the R&D laboratories of Bayer, Hoechst, and BASF.
> Whereas in the early days of the industry a firm could exist by copying dyes invented somewhere else, patent laws made the systematic application of science within the boundaries of the firm a critical dimension of remaining a leader in the industry.
Moreover:
> The most important institution in the early success of the German dye industry was the university system, but patent laws were a second key factor that allowed the German firms to capture a dominant position.
With that many assertions in the study that refute their view, they cherry-pick a few comments and actually cite the study as one that supports their view.
With so many accuracies in there, I find it hard to take anything else they say in that book at their word.
I commend that to the author in the spirit of learning about the space and thinking through the implications, because I believe people are more likely to solve problems when they understand what they are, and think through them, and don't just try to blunder past them with hope and moxie.
That post was written about generalized text annotation and I stand by it in that context.
However, as you deviate from the system being analyzed, the analysis becomes less appropriate. One of the problems generalized annotation systems have is that there are an arbitrary amount of textual comments that can be added to a page. That is what turns the popular pages into a unpleasant cacophony. The range of links is somewhat more restrained. Plus, links are just... links. Textual comments are arguing and flames and generally tiring on any popular page. (Though I'd watch out for people learning how to turn "links" into arguments.)
It is possible that a shared cross-linking system might work, but I'd strenuously suggest thinking very very hard before adding in any sort of inline "conversation" system. It is very, very obvious and very, very tempting... and it immediately puts you back into the generalized web annotation space, which is strewn with corpses, many of them very very well funded. You can have a "community forum" where people can talk, and perhaps even should, but putting it inline on the page is basically a known-fail. If you think you've got a solution to that I'd try to be very sure that you've got a very strong proposition on exactly how yours is different than the previous attempts.
Anyhow, I would just generally suggest to the author that this is one of those "obvious ideas" that hasn't happened because in general they flame out so quickly that you don't even find out they existed before they've already collapsed, not because nobody has ever tried it. Be sure to consider what has happened in the past.
Also, as a hint from previous efforts: It looks like you may be trying to bind links to specific text on the page. As you've probably already discovered, that's harder than it looks, and however much code you've written for it, I guarantee you it's even harder than that. I'd strongly suggest considering just binding links to pages and not trying to bind it to text at all.