Do you have any recommandations to help me with my understanding to the project, structure, database structure, etc.

I want to be a contributor to gitlab, but I am a freshman here. Do you have any recommandations to help me with my understanding to the project, structure, database structure, etc.

@EdwardZ I am also a freshman. I am just fixing small things that I can. One of the best advice I can give you is to learn HAML. That was a hurdle for me having mostly dealt with erb but the learning curve is not steep.

I am trying to fix a few minor issues that I see I have the ability to fix. Also check out feedback.gitlab.com for a list of suggested features. Sort them mainly by those with the status Accepting Merge Requests since they are more likely to be merged to the project.

Regarding how to contribute be sure to checkout this page

The BIGGEST hurdle you are going to have to overcome first is by actually using Gitlab for a while so that you learn the process flow such that when someone submits an issue you actually understand what they are talking about.

Other than that, Gitlab follows most of the usual Rails recommended conventions so don't worry if you submit code that is actually messy or doesn't work, someone will point this out to you so that you can rectify. E.g. Here is something I submitted yesterday. And here is my rectification in regards to the following conversation that I hope to be accepted :)

Note: Some of the submitted merge requests may be cancelled, mine have :). Its nothing personal..Hehe

For future purposes, what I am trying to do is to get to a point where I can follow @dzaporozhets quote on his team bio page -> He loves a good Martini and a merge request that can be accepted without comments.

To expound more on the structure, unfortunately you will most likely have to learn that by yourself. But if you are willing we can do a hangouts sometime and work together :)

@muthuri.kelmut already gave a pretty good explanation.
I'll just add my 2 cents.

1. Start small. Nothing is more frustrating than submitting a big merge request and have it rejected for some reason.
   Start with some small things. UI/Text fixes, documentation improvements. These things.
   After you got used to the workflow and the codebase a bit slowly tackle bigger things.

2. Hang out in the gitlab irc channel. A lot of users are reporting their problems there first.
   Usually some members of the core team will show up in it during the day and try to help.
   This is also your best option to get some pointers if your code isn't ready for an MR yet.

3. watch the MR discussions of other people and try to understand what's happening in them.
   If you see something that can be improved, write a comment.
   Most people will be open for improvements.

4. Sometimes the core team marks issues with the label easyfix. Those are a good place to start as well. Verify that those issues are still valid. (Especially after the big ui changes in 8.0) and submit an MR for them.

5. There are more ways to contribute than creating merge requests.
   We always welcome help in cleaning up the bugtracker and in the IRC chat helping users is always the right thing to do.

I hope this helps a bit.
I know it's confusing at first, but you'll get used to it pretty quickly.
When I started to contribute in febuary I had never seen a line of ruby code before

Awesome advise! @EdwardZ consider making your first merge request adding the advise above to CONTRIBUTING.md

It's been at least 2 weeks (and a new release) since we heard from you. I'm closing this issue but if you still experience this problem, please open a new issue (but also reference the old issue(s)). Make sure to also include the necessary debugging information conforming to the issue tracker guidelines found in our contributing guidelines.

Status changed to closed

mentioned in merge request !14785