I'm all for open source task trackers, but the UI in most parts is a rip off of Linear.
they wouldn't be the first
161–170 of 193 posts
I'm all for open source task trackers, but the UI in most parts is a rip off of Linear.
they wouldn't be the first
It's not so much "not JIRA", it's that managing code bases outside of the code base is hard and awkward. And due respect to fossil-scm, I don't know if any way to do it otherwise. The goal here is to look at something that tells an organisation why chnages to a codebase occurred. Each individual commit can have a nice explanation (in a given human language) of why that specific change occurred. But how does one link…
Why the need to reinvent the commit message? Look at how Linux does it. If it's good enough for a globally distributed organization creating the operating system the cloud and most phones run on, it can't be completely wrong. They rely solely on mail and commit messages. Ticketing systems are useful for a lot of other things such as keeping track of work on an individual level, or managing project resource allocation…
Most businesses hide the upfront discussion (or at least keep it to a smaller set of people who have often conflicting incentives for decisions as well (we tend to refer to this as politics but that's a bit like fish moaning about water.)
Anyway the point is that Linux shows how to make good decisions in the open (usually) - a process that I think most would 10x good decision making in most businesses but also lead to huge other sets of problems (worth it in my view but ...).
But Linux does not have a simple way of post-hoc justifying the decisions unless one reads the threads (which is where the recent post of open source journalist at lwn was a great idea)
But things like Jira, external ticket stores are good at providing a hierarchy to post hoc justify the decision - even if they are a terrible way to plan forwards.
So the ideal I guess is some kind of open architecture discussion upfront and some kind of extract and rebuild the rationale from commits (ie in house journalism?)
Earlier quoted context omitted.
I always go with discord in newer projects. Why? I feel like most people have discord nowadays and it just works (TM). I rarely have a case where a person said that they can’t join because they don’t have discord or don’t want to create an account because other reasons. Beside that, money is also a big factor. Slack for example is getting more expensive for communities.
It does not "just work," and you're not going to hear from me because I'm not joining yet another Discord server just to wade through searching through chat. Do a free forum. They've worked for 30 years and I might actually find my answer by Googling and won't need to even making a forum account.
The Plane codebase is a good read. If you want to see a well put together Django + Nextjs project you should check it out. There has been a lot of talk recently about what open source means. To completely side-step that discussion, I have plane starred on github because I learned a lot looking at their code without ever having run it or ever using the product.
The Plane codebase is a good read. If you want to see a well put together Django + Nextjs project you should check it out. There has been a lot of talk recently about what open source means. To completely side-step that discussion, I have plane starred on github because I learned a lot looking at their code without ever having run it or ever using the product.
Earlier quoted context omitted.
Also noticing copious use of select distinct within the views, which indicates issues with the schema. It may also partially be due to the somewhat limiting API provided by Django Rest Framework, which I personally tend to avoid. All things can be improved though.
Why do you avoid DRF? It's what keeps me coming back to Django over .NET Core or other API stacks (although I have yet to tilt at RoR in earnest/anger).
The Plane codebase is a good read. If you want to see a well put together Django + Nextjs project you should check it out. There has been a lot of talk recently about what open source means. To completely side-step that discussion, I have plane starred on github because I learned a lot looking at their code without ever having run it or ever using the product.
It's all fair criticism. The lessons learned will only take you so far, so the caveat is that if you think it's a bad project then you're already above a certain level. Go you :) You might take it in the context that they are shipping a real product at a fair speed so where it deviates from ideal what you're seeing is the educated choices of the tradeoffs to make in a real business (which is a statement of the plane…
I remember looking once at a project me and some others got pulled into, where everything was working but the code was spaghetti (which, to be fair, is usually why I get pulled in), and they were having a hard time adding new features without breaking existing ones.
At first, our reaction was the same as many programmers; "Oh my god what have they done and why have they done it like this?!"
Turns out, the company was on the brink of extinction, had about two months of runway left and made this Hail Mary project to attract some new attention and eventually landed them new funding.
So the project was rushed, a lot, but that's OK, but if they didn't rush and wrote super shitty code, the company wouldn't have existed at all. They were OK with this, because they traded "existing today" for "refactoring in the future", which sometimes is the right call to do.
Earlier quoted context omitted.
It does not "just work," and you're not going to hear from me because I'm not joining yet another Discord server just to wade through searching through chat. Do a free forum. They've worked for 30 years and I might actually find my answer by Googling and won't need to even making a forum account.
With attitude like this, perhaps it is indeed for the better to not hear from you.
This isn't necessarily a bad thing; may even be a positive aspect. In a quickly changing project, maybe it's good if your documentation isn't too "sticky" and the solution to a problem isn't low-touch "read the docs" but high-touch "ask me so that I can experience the pain points"
> See what 2,300+ folks in a forum get up to oh okay > Join our Discord sadness. where's the forum?
It’s funny as I think discord is actually kind of harder to get into than the old irc method. With irc there was no history or permanence so there was a relationship between discussion and what made it into the project as source or docs. With discord it’s weird because the expectation seems to be on me to wade through hundreds or thousands of messages to find docs because there are people who hang out and read everyt…