Ask HN: Anyone Replace Jira with GitHub Issues?
25 comments
I have ticket only repos where people can create tickets. They get pulled into a project and mentions across repos are still shown with status. We create issues from a user form too! It’s nice to get away from using multiple systems and get conversations so close to the pull requests.
> I have ticket only repos where people can create tickets.
Nice thinking.
> We create issues from a user form too!
This is where the money's at. I'm assuming this was done via Github API + Generated Token. I was thinking of something similar to this, however using a Slackbot.
Nice thinking.
> We create issues from a user form too!
This is where the money's at. I'm assuming this was done via Github API + Generated Token. I was thinking of something similar to this, however using a Slackbot.
I guess one question is, why don't you want people to have read access to the code? IMHO if they aren't trustworthy to view code, they probably aren't trustworthy to be submitting tickets (or employed in any other roles in the org as well).
To actually answer your question, you can have projects that span multiple repos, but you can't have repos that only have permissions for issues.
In my org, we have a few different repos for documentation + issues related to specific groups and utilize those repos heavily. We also have a couple code repos and anything specific to that codebase is stored there. We use zenhub though as well to help organize / track stuff.
To actually answer your question, you can have projects that span multiple repos, but you can't have repos that only have permissions for issues.
In my org, we have a few different repos for documentation + issues related to specific groups and utilize those repos heavily. We also have a couple code repos and anything specific to that codebase is stored there. We use zenhub though as well to help organize / track stuff.
I might be security LARPing but if someone doesn’t need to read the code to be able to do his job he just shouldn’t have access to do it.
Person might have been trustworthy when they were hired and they might change their mind at some point.
Even better - they still might be trustworthy but their computer got compromised and someone might be using them.
Maybe some other employee has problems with them and since they have access malicious employee can indicate trustworthy one in some way. Like posting copy of code somewhere online with nickname used by that one.
I know such things don’t happen often but even for mundane things like phone numbers you just don’t give phone number of your friend to a person you both know without asking that friend in first place.
Person might have been trustworthy when they were hired and they might change their mind at some point.
Even better - they still might be trustworthy but their computer got compromised and someone might be using them.
Maybe some other employee has problems with them and since they have access malicious employee can indicate trustworthy one in some way. Like posting copy of code somewhere online with nickname used by that one.
I know such things don’t happen often but even for mundane things like phone numbers you just don’t give phone number of your friend to a person you both know without asking that friend in first place.
I’m an actual security guy, been doing it for nearly 20 years (before it was a thing). I’m of the opinion that if I can’t trust people to look at code, they shouldn’t be at the company. Period.
There are very few use cases where I believe read only access to code from people in product, engineering or support should be restricted. Generally the net benefit is well worth the potential risk introduced.
If you are worried about people stealing source code, invest in a DLP or CASB solution. If you are worried about ransom, don’t allow changes without PRs, implement a backup program and harden your endpoints. Not allowing people to do things that helps them understand the systems they work with is a recipe for shadow IT and promotes organizational silos.
There are very few use cases where I believe read only access to code from people in product, engineering or support should be restricted. Generally the net benefit is well worth the potential risk introduced.
If you are worried about people stealing source code, invest in a DLP or CASB solution. If you are worried about ransom, don’t allow changes without PRs, implement a backup program and harden your endpoints. Not allowing people to do things that helps them understand the systems they work with is a recipe for shadow IT and promotes organizational silos.
Kinda get your sentiment, but you missed parents point. Whoever creates tickets SHOULD be able to at least skim code, do basic PR reviews, test a build. "I create tickets only" sounds like a toxic role.
Exactly. If you are capable enough to file useful tickets you are capable enough to read the code, run it locally, test out changes, tweak copy, etc.
You are wasting money paying people to write tickets and not read code.
You are wasting money paying people to write tickets and not read code.
I think you have a very narrow view of software development practices. In most companies I've worked at, most tickets are created by the QA team, few of whom have ever seen the source code and there's no reason why they'd ever need to.
They raise a ticket about the problem they encounter, and then other people triage it and try to find a way to reliably repro the issue, and then it gets passed to the development team when there's something actionable.
They raise a ticket about the problem they encounter, and then other people triage it and try to find a way to reliably repro the issue, and then it gets passed to the development team when there's something actionable.
I've worked in various companies as a developer and my worst experiences were where access to code is restricted, but BA's create these esoteric tickets with about 3 words in description...
I'm happy for them to raise tickets within their realm (and by the way lets not conflate support tickets vs actual work items), but please have some manager sift them thru into something meaningful.
I'm happy for them to raise tickets within their realm (and by the way lets not conflate support tickets vs actual work items), but please have some manager sift them thru into something meaningful.
What’s toxic about it? Tickets have a business need. They may have notes on implementation but if they aren’t serving a business need why do they exist?
IMO business needs shouldn't be a ticket - have some refinement first then explain clearly what do you want me to do.
IDK why it's hard for me to explain my sentiment, but I've worked in corp environments with large teams of averages using JIRA vs small teams of smart remote people. In the later my tickets were almost always very clear resulting in 1 or 2 short and tactical meetings per week. In corp environment I have 10 meetings per week spanning hours. The productivity is easily 10x worse.
IDK why it's hard for me to explain my sentiment, but I've worked in corp environments with large teams of averages using JIRA vs small teams of smart remote people. In the later my tickets were almost always very clear resulting in 1 or 2 short and tactical meetings per week. In corp environment I have 10 meetings per week spanning hours. The productivity is easily 10x worse.
Exactly, the best software products are open source, of course many bad ones are also open sourced, but proprietary software that must be kept secret -- even within the company -- are usually not the best. Even for the hypothetical scenario where they are leaked - they would only make sense in the context of your business, as such should be mostly worthless to anyone else (but it may expose the degree of competence, and potential attempts at security via obscurity, so could still be very bad news).
Intellectual property?
Yes, we have a single tickets repo seperate from the code, and use GitHub projects collect tickets from multiple repos into one board.
Team of 8 devs + other supporting roles. Devs are happy with it, PM and portfolio management not so much, as you loose a lot and GitHub projects is still fairly new.
Why did we do this? We were acquired and the new corporate has different ideas and we lost Jira. Project managers end up manually syncing status of epic tickets between GitHub and their project management tools. We make it work, but much more labour intensive the Jira+Jira Portfolio
Team of 8 devs + other supporting roles. Devs are happy with it, PM and portfolio management not so much, as you loose a lot and GitHub projects is still fairly new.
Why did we do this? We were acquired and the new corporate has different ideas and we lost Jira. Project managers end up manually syncing status of epic tickets between GitHub and their project management tools. We make it work, but much more labour intensive the Jira+Jira Portfolio
We are in the process to replace Jira, Bitbucket, Jenkins, MediaWiki with Gitlab. Looks good so far, but I don't know any details. We didn't have to write any code for the transformation.
What's your plan with documentation - wiki or markdown files in source?
Google seems to document everything in repo - which is brilliant since it can be reviewed, you can ask PR author to update doc and hence less likely to go out of sync.
Google seems to document everything in repo - which is brilliant since it can be reviewed, you can ask PR author to update doc and hence less likely to go out of sync.
> wiki or markdown files in source
Exactly.
Exactly.
what's your underlying motivation to eliminate jira & notion?
Not the OP here, but I think anyone who has used Jira understands the want to get rid of it—it is simply trash.
Not saying that it isn't, but I'm curious, what's your reason for saying Jira is trash?
It's agonizingly slow
Among others, regulatory reasons can mean Jira is not an option (medical, financial, export controls etc). They removed their self-hosted version a while ago, and their "data center" version is a $42,000 _minimum_.
Atlassian IBM speedrun.
There should be plenty of open source alternatives, and the times are really bad now to justify expenses like this.
There should be plenty of open source alternatives, and the times are really bad now to justify expenses like this.
Question: Is it possible to create tickets for a repo without granting read access to code?
If not, is the work around to create a repo just for tickets that everyone has access to? Is it even practical at this point?
Has anyone successfully pulled this off at their org?