I'm wanting to centralize tickets & documentation in Github, and in the process eliminate Jira & Notion.<p>Question: Is it possible to create tickets for a repo without granting read access to code?<p>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?<p>Has anyone successfully pulled this off at their org?
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 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).<p>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.<p>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.
Yes, we have a single tickets repo seperate from the code, and use GitHub projects collect tickets from multiple repos into one board.<p>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.<p>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?<p>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.