+1 Gitlab is awesome! Cool community oriented developers and a ton of more features. I see no reason too use github when gitlab is just better. It's also offered as a self hosted service.
I find the GitLab issue board to have a poor UX. For example, depending on where you click, it will open a small summary to the right or it will open a new page with all the issue information.
Also, it is ridiculously expensive to have epics, compared to every other issue tracker I have seen, in GitLab issues.
Hi Eduardo, I'm a UX Designer at GitLab working on issue boards. If you click on the issue title, it will open the issue in a new window. If you click somewhere else in the issue card, it will open the summary sidebar. But I agree with you that it can be confusing and not the best UX! To improve it, we are planning to redesign the sidebar so that you can see most (if not all) of the issue's information, removing the need to open the issue in a new window. You can track the discussion and designs in this epic: https://gitlab.com/groups/gitlab-org/-/epics/383#note_108940... Feel free to participate and share your thoughts.
I'd love to hear more about your painpoints with issue boards (and issues in general).
Hi Eduardo, thanks for writing about your experience with GitLab Issue Boards.
Could you please tell us what could make your experience more convenient? Do you have an open issue regarding your suggestions? If not, it would be great if you could open an issue about it at https://gitlab.com/gitlab-org/gitlab-ce/issues. We'd like to follow up on it.
It’s really valuable for us when users take the time to submit issues for bugs, changes, or feature proposals. This helps us steer the product in the right direction.
Can I remove old docker images from the registry yet? Heck, I still can't order by date, which should have been the default all along. Why would anyone want to see the images ordered alphabetically?
It can take minutes to page through and find the most recent image buried among hundreds.
I'm sorry this has taken so long, but we are working on some foundational API's to manage and list images right now: https://gitlab.com/gitlab-org/gitlab-ce/issues/55978. I've also added your feedback on sorting, thank you!
We are also setting up a team to focus on just packaging related features within GitLab, like the Registry, which should improve our velocity in this area.
I might recommend reading "Kanban from the Inside" by Mike Burrows. Where "Kanban in Action" is a very practical explanation, "Kanban from the Inside" focuses on the core values.
Afterward, assuming you have the basics of Kanban under your belt, I would recommend reading "Kanban Maturity Model" by David J. Anderson and Teodora Bozheva. It goes into great detail on specific Kanban practices, but it's hard to recommend this book unless you already have a good grasp of the basic concepts.
To be clear, kanban cannot be directly compared to agile. Kanban is a tool, not a process, framework, or manifesto.
In all work, you have Done, and done. Capital-D done is when something is ready to be shipped (note: doesn't mean error free, just means it's as far as you're getting). Lower-d done is intermediate states. The kanban board allows you to capture those and relate it to your workforce and workload.
If I have 5 developers, practically speaking we cannot be working on more than 5 development tasks at a time. The kanban board visualizes how much we have going on and allows us to see when we've overreached. If I have 2 tech writers, again we can practically only work on up to two changes to the manual at a time. The kanban board visualizes this, and makes a useful tool within any production or development workflow.
Capital-D Done is that final column (integrated into the master branch, sitting on the loading dock, whatever). Lower-d done is captured by movement between states (Dev -> Test -> Review -> Manual Update -> Done). Of course, it also should be noted that movement can be backwards. This isn't Waterfall, we know that something may move back to dev or test from test or review.
The particular utility with agile is that it helps address the agile manifesto preference for people over processes. A process expressed on a kanban board is not set in stone (as a formally signed off Capital-P Process document would be in a typical enterprise shop). It's much more fluid, and can be redefined to capture the level of information needed by the team and those they work with (partner teams, or management).
Well, the example on the site show it can be pretty simple (I never had use for it, so I never really tried it ), and formatting could be easely added by editing a classic text file...
So the machine that would convert latex to PDF doesn't have to be the one the text files are written with.
TeX (and LaTex) is pretty old, and designed to run on machines much less powerful than what we have today. Back then, I've used LaTeX on MSDOS PCs with 640 kB of memory. And the original TeX was written in 1978 for a PDP-10.
Many distributions are indeed big and clunky because you get lots of packages and fonts all in one, and there's no good way to selectively install.
Or do you mean verbosity when writing the markup? Actual text doesn't require a lot of markup, and you can make things even simpler by defining your own commands.
