@barbarar you shouldn't need ops access. please visit lists.wikimedia.org, subscribe to mobile-l, and then you should be able to send & receive mail to/from mobile-l@lists.wikimedia.org.

remote: Permission to wikimedia/wikipedia-ios.git denied to barbaramartina.
fatal: unable to access 'https://github.com/wikimedia/wikipedia-ios.git/': The requested URL returned error: 403

This is because you're not a "collaborator" or "owner" of the GitHub repo. You'll need to fork the project, then submit a pull request for the changes on your fork. If you're unfamiliar with the GitHub workflow, please read their docs on how to collaborate using pull requests and feel free to ping us with any questions you may have. The setup/workflow for you should involve:

1. Forking the repo
2. Cloning the repo and setting it up with both remotes:
   • Original repo (sometimes called origin or upstream) pointing to wikimedia/wikipedia-ios. I'll refer to this as the "upstream" remote for clarity, since origin is the default remote name and can refer to either depending on what you already have cloned
   • Forked repo (I usually just call it bgerstle when I fork projects under my user)
3. Checking out upstream/master so you can easily pull upstream changes and ensure your pull requests are based on the latest upstream code
4. Checking out a feature branch to make your changes in (i.e. git checkout -b feature/foo)
5. Now you can make as many commits as you want, then push them up to your remote (i.e. git push -u barbar feature/foo)
6. Go to the original repo, and create a pull request to merge the changes on your fork to the original repo!

@BGerstle-WMF thanks! I supposed I should work as a collaborator.
I will fork the repo and will create a PR.

Regarding the UML tool... any suggestion? or could I use any I consider good?

@barbarar RE: UML docs, we haven't given documentation too much thought, but what we've done so far is comprised of:

• High-level, conceptual markdown docs for various things
• Doc-comments in headers (as seen in various places in the code, e.g. [WMFImageController.swift](https://github.com/wikimedia/wikipedia-ios/blob/master/Wikipedia/Code/WMFImageController.swift#L137) and [MWKList.h](https://github.com/wikimedia/wikipedia-ios/blob/master/Wikipedia/Code/MWKList.h#L18), from which we might eventually generate HTML docs using a tool like Jazzy or appledoc.

In other words, things that are as close to the source of truth (i.e. code) as possible, making it easy to discover and update. We might employ some diagrams in the future, but the architecture has experience a high degree of volatility until recently, so now might be the time to start sketching things out.

I see... so it might be better not to generate any UML docs now... I was thinking about reviewing the project looking for not used methods and unused classes... what do you think about that? I think is very important to have the base source as small in size as possible, makes knowledge acquisition easier and faster, as well as keep the code updated with the functionality is really used... I do not know if there are unused classes or methods... but if it were the case it might make sense for me to do this task also as an initial contact with the code.

@barbarar we're always happy to see dead code get deleted!

I'll try to get the team to start doing this more diligently, but there's an good first task project/tag which is meant to help new contributors find tasks to work on. Unfortunately, there's only one easy task in our backlog & dev boards 😔.

if you're feeling brave, you can look through the "Needs Triage," "Bug Backlog" and "Ready for Dev" columns on our product & dev boards for tasks that seem small and/or well defined.

mm... ok, I will check these task categories on Phabricator... anyway I
will do the code cleanup, it's a good way for me to start... I will do a PR
might be and you can just ignore it until you decide it would be worth to
integrate or not... I would not like to start doing any task until I get a
taste of the code and architecture... so in the meantime I will do
things to approach the code from different angles, it's ok if the PR are
not integrated... or I don't know might be I will just do it on my forked
version... or in a local one...

@barbarar sounds good, i'll be sure to mention you if I come across a task that I think would be good to start on (and tag it as easy).

Great thanks ! Talk to you soon