No magic involved, earlier today the repository had a visibility of "internal", now somebody flipped a switch and it's now "public". On Sun, 14 Jan 2018, 5:15 p.m. alvinpenner, <penner@...1856...> wrote:

FYI I filed a bug for the issue (or at least an issue) I found during this: https://gitlab.com/gitlab-org/gitlab-ce/issues/42022 Not sure if this is what you hit Bryce (group level should be unaffected but a project level the UI for the setting to allow requesting access is broken). Regards, Eduard Am 14.01.2018 um 18:21 schrieb Bryce Harrington:

On Sun, 14 Jan 2018 09:21:33 -0800 Bryce Harrington <bryce@...961...> wrote: Hi, maybe related to this: I am not able to create new issues for the "inkscape" project. When visiting https://gitlab.com/inkscape/inkscape/issues/new I get "404 - The page could not be found or you don't have permission to view it.". Creating issues for other projects (e.g. lib2geom) seems to work. I am regularly logged in to gitlab and I don't have special permissions for any Inkscape repository on gitlab. Ciao, Antonio -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?

On Wed, 17 Jan 2018 19:01:19 +0100 Maren Hachmann <maren@...3165...> wrote: Thanks for the remainder Maren. I knew about the launchpad pages but I didn't check the "Report Bugs" page before asking, I just assumed that since the code was on gitlab, new bug reports had to be filed there too. My bad. Ciao ciao, Antonio -- Antonio Ospite https://ao2.it https://twitter.com/ao2it A: Because it messes up the order in which people normally read text. See http://en.wikipedia.org/wiki/Posting_style Q: Why is top-posting such a bad thing?

On Wed, Jan 17, 2018 at 11:23:34PM +0100, Maren Hachmann wrote: If anyone feels motivated to put some time into moving this forward, let me know. The next steps are analytical -- essentially requirements gathering, and assembling a listing of questions that need researched. Should we move bugs to gitlab? Or stick with Launchpad? Or investigate other bug systems? Or something else completely? There's several different constituencies with differing needs that'll need to be balanced. It'd be great if we could find a plan that works well for bug reporters, triagers, and developers. Bryce

If we do move them can we get back to separate categories of bugs and feature requests like we had on sourceforge before we went to launchpad? I know we have blueprints on there too, but they always seemed over complicated for simple stuff. Never liked the way launchpad merged them. Cheers John On 18 Jan 2018 3:57 pm, "Martin Owens" <doctormo@...400...> wrote:

On Thu, Jan 18, 2018 at 04:05:23PM +0000, John Cliff wrote: Yes, and I've heard this stated from a number of others too. While moving to launchpad from sourceforge was a benefit, conflating these two types of issues was a drawback. The loss of being able to prioritize feature requests as we'd done in SF was particularly unfortunate. I had high hopes for the Blueprints system, but frankly the design was flawed and the implementation of it never really evolved or even kept up with other advancements in LP. It had potential, but I have a lengthy list of changes I would like to have seen to make it useful to us. Ideally, I would love to have an entirely separate system for organizing feature requests. It would allow us to prioritize and refine the ideas, organize them into project lists for GSoC and the like, feed into our Roadmap, facilitate crowdsourced funding, and stimulate development activities. Anyway, all cards on the table for now, but I do suspect splitting these apart is going to be on everyone's must-have list. :-) Bryce

On Thu, Jan 18, 2018 at 10:12:16PM +0100, Eduard Braun wrote: I tend to agree, but have to acknowledge that there's a risk of putting too much burden on end-users to select where to report their feedback, when they may simply not know enough to make that determination. Or at least may not feel comfortable with it. Part of the argument of the two-layer approach would be to address this by having a one-stop-shop inbox that is friendly and suitable for non-technical users. And then a second layer where the individual items are broken out into more technically detailed repositories which are sensibly grouped in ways that are more manageable for triagers and developers. So yeah, being able to move things easily from the friendly 1st-layer inbox into the appropriate 2nd-layer is critically important (if it's hard to move things, no one will bother and it'll be piles of fail). Having everything contained on the one platform would likely have some benefit to it. gitlab's trackers also allow defining tags and stuff per-tracker, so we could have the bug tracker have bug-oriented tagging and a feature tracker with feature-oriented tagging. A question in my mind is what the workflow for feature requests should be, and if that workflow can be modeled appropriately within gitlab. But this is a good idea and should be considered further. Yes, there's a fair point there. Bug triage is a considerable amount of work - largely invisible, often thankless. If the rate of incoming bugs is high, it can also be an overwhelming job. So approaches that depend on human labor to process bugs or that facilitate an increase in incoming data is going to exacerbate the situation. Approaches that can eliminate or automate processing steps would help. Approaches that shift the work to the reporter may help the triage problem but risk creating other problems. For the two-layer system I've been mentioning, this in particular is a big risk, since the translation of issue from the first layer to the second would involve a significant amount of processing work, that isn't really automatable. My thought here is to structure it to be crowd-sourced - in other words, the external layer is messaged to be community-driven with community members earning rights to manage the content. I'm imagining something akin to StackExchange, or the old Ubuntu Brainstorm site. But with the advanced members being empowered to escalate items into the 2nd-level system. With a strongly crowd-sourced 1st layer, then our triage staffing commitments would be just for the 2nd-level systems. There'll be fewer items there and they'd be higher quality so the workload would be smaller and easier. I know a lot of companies used tiered tech support, this is basically the same approach, just with tier-1 being run and managed by the external community rather than the Inkscape project itself. I wrote up a conceptual blue-sky user story for the last Vectors team meeting: https://gitlab.com/inkscape/vectors/general/uploads/5fd013b6e716f16ccc85f... There's a bit more discussion about bug tracking ideas here: https://gitlab.com/inkscape/vectors/general/issues/23 Bryce

On Fri, Jan 19, 2018 at 02:20:46AM +0100, Eduard Braun wrote: It's the latter. So if both splits were done there'd be three trackers (apologies if the ascii/unicode diagramming gets borked): +-------------------+ | Friendly Feedback | +-------------------+ ↓ ↑ Crowdsourced Triaging ↓ ↓ +-----------+ +------------+ Feature ← | Feature | | Bug | → Bug Triager → | Request | | Report | ← Triager Team | Tracker | | Tracker | Team +-----------+ +------------+ ↓ ↓ Developers Developers Developers Bryce

If the Feature and Bug report trackers are on GitLab, I think a friendly feedback / crowd triaging app could be made to talk their API with medium difficulty. If I were to craft one, I'd probably make it a separate project. If one already exists, then we could set that up localhost or staging to test it out. But I'd like to make sure any existing system isn't designed to be the principle bug tracker firstly.   Best Regards, Martin Owens

I like this idea too, so that we know that bugs in "bug report tracker" are actually reproducible and contain some info :) How do you think we should proceed for our existing bugs ?

Am 18.01.2018 um 21:30 schrieb Bryce Harrington: Now we have: http://wiki.inkscape.org/wiki/index.php/Bug_Reporting_Workflow Maren

Am 23.02.2018 um 01:47 schrieb Eduard Braun: - Thanks :) I hope it's going to help us move forward with that topic, although it's not really a fun/rewarding topic to start with, as it entrails a lot of work, has a high potential for too much discussion. Hopefully it's not going to be a lot of trial and error. - As for the bias, I think that's because I was listing current problems, and our current platform is launchpad... So, of course, the problems will have to do a great deal with launchpad... But the page is not static, you can improve the texts. I think it would be very beneficial if the people who are most affected by a change in that system (i.e. devs) would make their needs and wants clear, possibly on that page. It's good to have the vectors team thinking about bug filing templates and welcoming workflows and to have a documentation person write up a summary of issues, but we cannot reasonably do anything without devs. - We'd need a whole hackfest *month* dedicated to it... And then, I'm afraid, nobody would come, it's not fun to sort through old bugs... And it's not a task that any one group can do alone - devs of all specializations, users, testers etc. would all be needed to help. Even if we could get 20 persons to work on it, there'd still be 240 bugs per person... 10 a day - mmh, that sounds almost doable. Bugathon, anyone?... - That would be another way to do it. Advantage: no or very little work for us and a 'clean slate', Disadvantage: lots of info lost, users annoyed (unless someone can explain it to users in a really, really good way). Kind Regards, Maren