[dijit]

(I upvoted you, for asking the real questions, but to answer)

> Where do you keep Issues,

Youtrack

> Pull Requests,

Gerrit, it's way better for code review

> Wikis,

Also Youtrack, but other software exists that's specific for this, I have seen Confluence used a lot and while I don't recommend: that's usually the case.

> Discussions,

As far away from code as possible, right now it's Zulip

> project boards,

Youtrack, though usually in companies they use Jira for this.

> and everything else? (rhetorical question.)

In proper tools that are designed to solve a specific need, not try to do everything: badly.

--

Now, a sane person will respond to me with the fact that I haven't removed any single points of failure, I've actually just added more of them. They'd be right! The differences is that it makes the stack a bit more flexible and composable. Migration of, say, the Wiki, doesn't make major issues because it's already somewhat decoupled.

[thayne]

For a large project with dedicated resources that is pretty reasonable. And GitHub issues probably isn't sophisticated enough for you anyway. But for a small to medium open source project, that's a lot to set up and manage, and in the case of gerrit, you have to host it yourself.

And then for Youtrack, Jira, Confluence, etc. You still have the same problem where it is difficult to migrate to a different system, because the data is all stored in a proprietary format that can't easily be ported to something else. For the wiki, there are somewhat standard formats used by multiple systems, like markdown and mediawiki. But for issues, I don't know of any standardized format, and migrating from one product to another is going to be pretty difficult.

[locknitpicker]

> Now, a sane person will respond to me with the fact that I haven't removed any single points of failure, I've actually just added more of them. They'd be right! The differences is that it makes the stack a bit more flexible and composable.

Not really, it sounds you made a mess of things by having to rely on a dozen small disjointed services and separate account and auth needs instead of just using a single integrated environment.

There are many reasons why a service like GitHub is really not about git.

[dijit]

its funny how many people came to me as if I invented this and that I’m wrong by default, but I have never worked in a company that only used an all-in-one solution.

[geekone]

would a self-hosted all-in-one solution be a viable alternative that doesn't split these all up into separate cloud hosted apps? it's been years since i've explored anything other than github/gitlab/etc.

[wps]

Fossil does all of this, and has a better VCS for my use case than git does. https://fossil-scm.org

[48terry]

Right? Yeah, everything's decoupled and "flexible", but if your stack is dependent on half a dozen different third parties uninterested or uninvested in your project, you gotta watch like a hawk for when those services decide they need to be worse and charge more.

[fragmede]

Like a hawk? If GitHub was down while you slept, would you notice?

Those third parties will be more invested in you as a customer than GitHub is.

[rsyring]

> In proper tools that are designed to solve a specific need, not try to do everything: badly.

And when you want to search for that one thing that you know got documented somewhere, but can't remember where, how many systems do you have to search?

That's one of the reasons I like the code, issues, docs (code or wiki depending), and discussions all in the same repo.

Not to be confused with Chat, which is more ephemeral, and is, for us, in Slack. But we have to be mindful of chat discussions that turn substantive and make sure we copy that info to a Discussion in the repo (which can be annoying to do and annoying when it's not done).

[skydhash]

> And when you want to search for that one thing that you know got documented somewhere, but can't remember where, how many systems do you have to search?

Not GP, but is that actually a real problem? Take a project like OpenBSD where the code, the bug tracking , and the design discussion happens in different place?

Even in reality, you don’t put the workshop in the conference room.

[rsyring]

We are a software dev/consulting company. We have a lot of client repos and a lot of different internal teams. It's a real and significant problem for us and we are a pretty small org.

I've done consulting with bigger orgs (Fortune 500) and the more systems they have the harder it is to find things. It's a problem for them too.

So..in short, yes it's a real problem.

[hluska]

I don’t get it. That’s a lot of failure points to incur in the name of flexibility.