I want to also stress that the new interface does not communicate the different options available very well. The old wizard had radio buttons with things like "have phabricator host your repo" and "host your repo outside of phabricator".

Once you hit the CRUD interface, there's absolutely no indication that anything can be done differently. You have to know what tabs to go to and what dropdowns to pick to then magically turn it into a non-hosted repo.

Thank you for the timely response. I'm glad to hear you're thinking about this. I still have many concerns about this that I hope you will consider.

Here's what I have, which possibly contributed to my confusion.

1. From your post I don't know if the circled area is new since the June 24th build I last updated to (I update once a month to stable), or if I have a configuration problem on my end stopping it from showing up.
   
   Until I update at the end of the month, I also can't tell if it's a link to a 4th wizard, or from what I can tell in the screenshot, just a link to documentation.

2. If it is a link to the documentation, and not another wizard, then the process was still changed, the old wizard is gone, and the new process for non-hosted repositories is confusing and non-intuitive. Documentation does not change this, merely helps users navigate the problem. I would like to see this improved or reverted to the old wizard for the creation process. Even if you retained the confusing (to me) CRUD interface post-creation, that would still represent an improvement over the current state.

3. I was not talking about the ambiguity of the word import, I agree with T9679 that import is confusing when dealing with non-hosted repos, maybe observe is better. But the loss of hosted vs non-hosted is what I was talking about. In the new workflow it says hosted at first, and only after you add a url with observe does it change to non-hosted. It could do more to point you to the option to make this change from within the GUI, and to indicate that this is what this option does.

4. Lastly, since I didn't have a link to the docs the image above may link to, I went looking. I ended up here: https://secure.phabricator.com/book/phabricator/article/diffusion/ and the Overview mentions hosted and non-hosted repos. The Adding Repositories mentions hosted repos, but does not mention non-hosted repos. You have to go back to the index and find https://secure.phabricator.com/book/phabricator/article/diffusion_uris/ at random to discover where non-hosted instructions are. It would be helpful if the Adding Repositories had a bullet linking to this document directly for non-hosted repos. The wording on the index could even be improved, I'm not sure fetching hints enough that this is where non-hosted repos would be, though I realize the index should be very succinct so this is a difficult call.

Thank you

@ofbeaton How can we make the bug reporting guide more clear with respect that we don't take bug reports on older versions of Phabricator? Nor do we take feature requests or feedback as bug reports.

These guidelines and rules exist so that developer time is spent working on Phabricator, not answering questions that don't exist at HEAD or have been previously discussed in other tasks. Providing free support is the largest cost that currently exists in building Phabricator.

We really want community members, especially frequent ones, to do their part in helping us build Phabricator. The easiest way to do that is following our Support Resources guide, due diligence in keeping up to date and searching before filing anything, as well as being mindful of the free product and free support you are receiving. If we allow people to ignore the guidelines and file anything, anytime, we'll be too overwhelmed with support to move Phabricator forward, and that's something we just don't want to do. See T9212 for previous discussions on this topic.

First I apologise if I somehow came across with any hostility, that was certainly not my intent.

@chad I personally don't think being a few weeks behind HEAD is unreasonable. I run stable updated once a month, which is already a week behind, and the documentation states this is the version Phacility runs as well. I thought this was pretty good updating on my part, but you make it sound like I'm a horrible administrator. I'm exploring ways to automate it, though I'm concerned of waking up to a broken install. Do you really expect us to be updating daily against a version phacility itself does not run?

If you are serious about wanting ideas on how to reject any submission from anyone not running HEAD, then add required version fields to the submit form and have it display a rejection the moment they put in a version behind HEAD.

I put a lot of thought to if this was a feature request or bug report, but since an existing workflow was changed from being clear, direct and understandable to in my mind; confusing, fragmented and ambiguous, I considered it a bug report, is that not correct?

You can be assured that I searched multiple times and went through over 10 ticket threads. This does not always reveal existing tasks or discussions.

I am more than sympathetic to your support costs, and the benefits we get from phabricator for free. Indeed I agree, I want to do my part in helping you build phabricator. In my mind, that includes reporting problems.

I didn't need help in figuring out how to do something, I managed that on my own. I reported a problem when a process was made worse and difficult to use. I have seen phabricator staff say well nobody has complained about this, so we don't see a problem.

Here is your complaint.

In general we want people to update if possible before filing a bug report. The reason is most real "bugs" are fixed usually same day reported. For example we had a recent "Repository is not attached" exception that was fixed same day, but we're still getting reports trickling in weeks later. Being on this week's stable is all we usually expect. HEAD of master is better, but not required.