Open Stack

>> 
> 
> The point I was trying to make was more that nothing stops that contribution from happening today on Github if that is where those individuals prefer to be. What changes if the repo moves under the Github openstack organization and we formally add the project to openstack governance? There are some changes for sure, but most aren't going to be visible/important to those individuals.
> 
> I'm trying to get us to be explicit about the benefits and cross check them against our goals. I'm not necessarily saying it is a bad idea. It may be that those people want to vote in TC elections and have a greater say in the direction of openstack as a whole. If that is the case let's say that and make sure that benefits like that align with any goals of such a move.
> 
> I'm not saying that contributions like that don't benefit the ecosystem. I'm specifically trying to understand what benefits to this specific change there are to both parties. It isn't clear to me if part of the move is explicitly ignoring the way openstack has chosen to do things.
> 

Let me give here couple of examples:

- When I am doing some bigger changes in SDK/OSC/Ansible it is logical to have a devstack running locally to be able to try it out and somehow ensure tests will work without burning CI in endless patchsets due to typos and other type of bugs. Chances that I will be able just to start devstack on my laptop and it immediately works are terribly low. I am not going to go into details why, this is not relevant here. Due to this in most cases, unless I do something much bigger and ready to invest eventually 1-2 hour to get devstack running I skip this and go into the blind flight relying only on CI. And as mentioned earlier producing sometimes lot of patchsets.
- My contributions to Zuul are actually facing very similar challenge. I am able to reverse engineer how to be able to run tests locally, but honestly this is not something I really want to do, especially in a fast evolving software. Due to that for fixing one bug I am spending 20 patchsets and weeks of time (everybody here know perfectly how much time we usually wait for CI results and endless rechecks). With that I honestly think twice, do I have enough “free time” and commitement to try fix the bug properly or I have a workaround I can apply in my installation
- I have seen from other teams, but now talking explicitly about myself: using storyboard is so inconvenient that I just stopped using it (neither for reporting myself, nor looking what others report to my projects). I even see often people reusing some external issue trackers just to make it somehow usable (I am waiting so desperately for us finally enabling gitea issues)
- Very often when somebody is asking me about particular place in code they (and this is often valid for the referred super contributors) share link to GitHub and not opendev.

What I am trying to say with that is that there are convenience factors we should not neglect. Once developer feels not comfortable with the contribution workflow he/she will not do this at all, unless he/she is a long-time committed contributor. Users willing to report issue in OSC/SDK/Ansible area often give up on that after seeing what they need to do in order to at least report the issue. I give up on tracking what users report to the projects I am responsible for in an official way. The ones willing to contribute a small fix give up after seeing their PR is auto closed.
This is not about: we are bad. This is about if developer doesn’t feel comfortable in the work we will not win him for us. This is something I learn through pain during last 10 years or so.

I am very glad to hear that proper SSO is moving closer. Also awesome to hear we may be close to get issues feature of gitea. Those are the things that should make daily life a tick easier and we may really improve this. 

Artem