Hey I'm the Community Manger at Mattermost, if yall do build the integration and need any help with anything, feel free to reach out to me ([email protected]) or join our community server http://community.mattermost.com/
I'm not that familiar with Flowdeck so I don't know if this is what you mean, but "collapsed threads" in Mattermost is just a personal view setting that can be turned on/off according to your preferences.
The Mattermost team is working on automating feature testing of the webapp to
1. Decrease time to ship a bug fix release
2. Raise the quality of the software by reducing number of manual tests
Our end-to-end (E2E) tests, written in JavaScript using the Cypress framework, help us cut down manual tests, and are an integral part of the product development process.
Event Details
1. Event runs from May 3rd to May 31st, 2021. Any submitted PRs must be merged by June 11th 4:00 PM PST to qualify. Those closed by maintainers as incomplete, invalid or spam are not counted.
Yes, if the support ticket is opened when the issue is discovered. This particular instance was first reported on hackernews and was due to our dormant namespace policy: https://news.ycombinator.com/item?id=23827772
I wouldn't worry about that, we have clear conditions that need to be met before we release a username [1]. It's meant to prevent name-squatting, not take usernames away from actual users. Although I do want to point out that GitHub also has this [2], it's just worded differently and doesn't outline what they consider "inactive".
Oh no I agree, that was just a comment recognizing that my experience is different because I'm in a more ideal situation than other developers are surely dealing with. I still passed along the feedback to our product team!
Thank you so much for the feedback! I'm asking around to see if there are any projects open to reduce the number of pages, but I do know for sure that reducing page load times is an issue we're working on. Here is our handbook page that outlines our current metrics and goals, our primary goal is to have a speed index of less than 2 seconds per each page on .com: https://about.gitlab.com/handbook/engineering/performance/
Thanks for the feedback! It's funny you mention the Auto DevOps documentation because we just had our new senior tech writer pick up an issue [1] to completely redo it, so hopefully it'll be more intuitive soon!
Thanks for the feedback! I passed it on to our content team to see if they want to make adjustments to the blog post. I definitely don't want it to come across as misleading.
That's interesting feedback, I'll pass it along to the product team, although this is an angle they've probably thought about more than I have. The way we use it isn't really as an accountability metric, more of an estimate that can change dynamically when new problems arise so we can roughly plan out when a feature is going to be released. Granted we don't have a boss who would beat us over the head with that. Thank you for the feedback though I'll make sure to pass it along.
Hey! GitLab employee here. The speed of the site has been on our radar too, we have a handbook page [1] detailing our metrics and our goals. Ultimately we want to have a speed index of less than 2 seconds for .com, but we know we aren't quite there yet.
As for the UI being unintuitive, I'm sorry to hear that. Everyone has different UI preferences so it's understandable. If you want, we're holding a competition right now [2] for anyone who writes a review of GitLab vs GitHub if there are any specific features within GitHub's UI that you like better!