@rainbow are you able to find @florianrappl via slack, kindly tag me too in the call discussion for coming a up with a microfront end documentation for getting started
I 've sent him a slack message. Will include you for sure.
@herbert24 @grace @jennifer @ibacher @dkayiwa Based on your input, I have created a new wiki page hierarchy for the āGetting started as a developerā part. Itās here
Some of the titles are for files that do not yet exist. The titles that have links already exist but live elsewhere on wiki The yellow titles are files Iāve updated.
Please provide your thoughts and comments. Thanks!
@rainbow Iāve added some suggestions to the Getting Started as a Developer google doc, namely to address these top problems Iāve been noticing (@madhens I think it would be awesome to incorporate these into our general onboarding in the future; but for now we should probably include these in the dev onboarding so people donāt miss out on this info):
- Encouragement to join active projects: Devs seem overwhelmed by our curated intro tickets. They either donāt know where to find them, or thereās too much to learn for them to get started contributing to them. Better practice would be to plug contributors into small teams of people working on things theyāre interested in, so that they build some community relationships and quickly have a small support system of people.
- Where to find info about our events: It amazes me that even though most people use digital calendars to structure their lives, some people who have been around OMRS for years and years still rely totally on Talk to know what meetings/events are going on. How hectic! Letās help newcomers know where and how they can join meetings and conversations already going on. For example, I recently joined the DHIS2 community online, and couldnāt find how to join their meetings/calls/events - so I gave up.
Feel free to edit/cut down my writing!
The next thing that would be awesome for us to do for intro Devs is an easy way for them to get started writing some automated tests for our user-facing product. FYI Weāre working on a prioritized list of test needs (covered/not covered) that new devs could be directed to, but weāre not there yet.
Finally, FYI @rainbow and @madhens I added an extremely extremely light version of onboarding to the Active Projects page on the Wiki, because we learned that some companies (like ThoughtWorks) are referencing this page and their devs/UX/BAs were getting confused almost right away. It would be awesome to see the Personas, Site Example video from Nepal, and Community Video all included as part of the general onboarding that everyone goes through Does that make sense?
I think it would be ideal to have a āGetting Started with QAā guide to which we direct BAs, testers, and devs who want to focus on QA. Since we also want to make QA an integral part of the dev process, it would also be good to have a way to orient devs to our QA processes and tools. Could this be a short āAbout QAā section with a link to our QA pages thatās included in the āGetting Started as a Developerā guide?
This also brings us back to the question about tickets/tasks and where those live. Itās important to have consistent guidance for teams and squads about where to put their intro tickets/tasks and how we direct people to them. With the previous Getting Started as a Developer guide, the intro tickets were a part of the guide. I think it will be easier to maintain if squads simply tag any intro tickets in JIRA, on github issues, Trello, etc and provide a link to those who want to join a squad or team.
What do others think?
Iām about to go into a block of afternoon meetings but I think having specific āGetting Startedā information for the core teams makes a lot of sense, and for QA, tying it closer to Development could really simplify it instead of having QA both as a separate page and then part of the Developers page.
And I fully agree on the squads having a link to their Jira/Trello/etc tagged with good beginner issues on their āGet Startedā page, so it perpetually keeps itself current. Obviously, depends on if this is useful to the squad leads, but it seems much more intuitive from the viewpoint of a new user.
I would love to write instructions on that. Who should I talk to get more info? Will a link to existing unit test wiki be enough?
I will revise the instruction and put more emphasis on active projects! Great insight.Thanks!
3 posts were split to a new topic: Request for Comment: New Volunteer Guide