Change Details

== Profile Information Name: Formasit Chijoh Fokunang Nickname: formasit Github: Formasitchijoh Email: formasitf@gmail.com/manoica2023@gmail.com Phone Number: +237-675-718-328 Location: Cameroon Time Zone: Cameroon (GMT + 1) == Meeting with mentors: I am reachable anytime through email, slack, and any communication channel GMT + 1, 6:00 AM to 10:00 PM = Synopsis == [WikiEducation Dashboard] Improve the Wiki Education Dashboard test suite Wiki Education Dashboard is a Ruby on Rails application that provides server-rendered fronted and contains a with a mixed React and Redux. It provides tracking and statistics for hundreds of thousands of editors on Wikipedia and other Wikimedia wikis.The Dashboard codebase uses a comprehensive suite of Ruby tests, including unit and feature tests, to maintain functionality.However, the current test suite is fails often, taking approximately 35 minutes to run (on GitHub CI), and is overall fairly fragile, with intermittently failing tests .The focus will be on identifying and improving quality and performance of the test suite, optimizing execution times, and increasing test coverage. Strategies such as parallelizing tests, and refactoring slow tests will be employed to achieve a more reliable and performant platform. Improving the Dashboard test suite will drastically improve the developer experience and making the platform performant and scalable == Mentors Sage Ross(@Ragesoss), Sulagna Saha(@saha23s) = (In Progress) == Deliverables 1. Identifying and fix all test that fail intermittently 2. Establish a test suite that passes 20 consecutive runs on CI 3. Refactor, rewrite and improve code quality and test coverage of areas of the code holes in test coverage and write test for untested LOC 4. document test case that can evolve for future reference == Implementation Details The Major scope of this project will focus on the ruby rspec test suite, for the ruby on rails backend which contain unit tests of individual class files as well as browser-driven feature (ie, integration) tests that interact with both the client-side UI and the server-side behavior, hence improving this section will greatly affect the performance of the entire test suite. The primary focus will be evaluating the test suite and its recent CI logs to identify intermittently failing tests, their causes, and tests that significantly contribute to long execution times and proper evalution of external API that the system interacts with. The project will also target areas of the codebase with gaps in test coverage and LOC with unwritten test , rewriting both the tests and underlying code as needed === STEP-I The current API of the system currently through error intermittently, * The first step will be to run unit test each test for the different controllers, models and services in isolation to ensure it works as expected and identify any patterns of failures in the test, identify the cause of the failure and document them, * Features that utilize third party Api like the LiftWing Api, ReferenceCounter APi, Commons Wiki, WwikiApi, often fail intemittenly, due with at least some of these problems, the LiftWing API has different responses than what the specs were written around. to different responses returned than what the Rspec expect, these third party endpoint will be tested under different condition to analyze it response and update existing to cover the reponse gotten from this endpoint Rpec and code that use these enpoint. These endpoint will be tested, to identify its’s interactions with the system and Why it fails * Currently the the CI/CD pipeline takes approximately 30 to 35 minutes to complete, this is relatively slow for development purposes, recent Sentry logs and development logs will, be reviewed to identify the different failure, and how they have evolved overtime, and identify any pattern and dependencies. Using the most slowest apI request and test that are identified by the test suite, a timer will be used to identify the time that each of the requests takes and how identify how to optimize them. And improve the performance. * I am currently working on issue of writing comprehensive test for the javascript and ruby test suite and from the issue that was raised here i have been going through all the failures that have come up during the contribution stage and am currently fixing them, i ill continue to do so until outreachy result declaration and all through the bonding phase === STEP-I After proper analysis of the entire test suite and identifying the different causes of intermittent failures and their causes , The project will employee automation testing strategy that will range from * updating existing unit test to fix and accommodate breaking changes and write new unit test to improve the test coverage for the lines of code with unwritten test * Update test for external API and ensure existing test are written around the recent responses that are returned by the external APi and ensure all features that unilizes them use the appropriate format * After analysis of the current failures it noticed that major section of the test suite that posses an issue are with the revision, articles and course that uses the LiftWing API and the ReferenceCounters of the articles, each of these models controllers and request test case will be reevaluated to improve the find issue * All existing modules will be properly tested to ensure full test coverage, fixing any issues encountered and writing new integration test for new codes and will be tested and ensuring that all work as expected improving and writing new integration test for new feature * Each endpoint will be tested with different loads to see it’s stress level and impRove it’s performance, * Using Capybara to test the server rendered section of the test suite an tested end to end using the systems flow and ensuring all parts work toghether as expected. *Using Sentry logs, test suites will be improves to reduce test run and equally optimize test performance. * create new test Data configurations and ensure existing once are improved to work === STEP-III * Run end to test to ensure Existing iintermittent test failures are resolved * Write a guide to assist developers in navigating and diagnosing issues in failing tests * Implement a more intuitive and easy to understand reporting strategy for error logs and where exactly the error is from == Future Goals: Will be implemented if all above-mentioned milestones are achieved and completed successfully and approved by the mentors, also desired to be taken up after Outreachy. *Increase the JavaScript/JSX statement coverage to 90% *Continue monitoring the system platform to ensure all test pass properly and are effective and handle new code === Timeline === October 29 - November 26: * Continue making contributions to the Wikieducation Dashboard === November 26 - December 9 * Community bonding period === December 9 - December 14 (Week 1 ) * Begin with the user research to identify further areas of improvements in the existing test suites * The first step will be to run unit test each test for the different controllers, models and services in isolation to ensure it works as expected and identify any patterns of failures in the test, identify the cause of the failure and document them, === December 16 - Jan 5 (Week 2) * Features that utilize third party Api like the LiftWing Api, ReferenceCounter APi, Commons Wiki, WwikiApi, often fail intemittenly, due with at least some of these problems, the LiftWing API has different responses than what the specs were written around. to different responses returned than what the Rspec expect, these third party endpoint will be tested under different condition to analyze it response and update existing to cover the reponse gotten from this endpoint Rpec and code that use these enpoint. These endpoint will be tested, to identify its’s interactions with the system and Why it fails === Jan 7 - Jan 12 (Week 3) * create new test Data configurations and ensure existing once are improved to work * Currently the the CI/CD pipeline takes approximately 30 to 35 minutes to complete, this is relatively slow for development purposes, recent Sentry logs and development logs will, be reviewed to identify the different failure, and how they have evolved overtime, and identify any pattern and dependencies. Using the most slowest apI request and test that are identified by the test suite, a timer will be used to identify the time that each of the requests takes and how identify how to optimize them. And improve the performance. === Jan 14 - Jan 19 * updating existing unit test to fix and accommodate breaking changes and write new unit test to improve the test coverage for the lines of code with unwritten test Buffer time for previous weeks Mid point feedback Jan 21 - Jan 26 (Week 5) Discuss how to improve continuous new uploads Keeping up with the ongoing research * Update test for external API and ensure existing test are written around the recent responses that are returned by the external APi and ensure all features that unilizes them use the appropriate format *Using Sentry logs, test suites will be improves to reduce test run and equally optimize test performance. January 28 - Feb 3 (Week 6 ) After analysis of the current failures it noticed that major section of the test suite that posses an issue are with the revision, articles and course that uses the LiftWing API and the ReferenceCounters of the articles, each of these models controllers and request test case will be reevaluated to improve the find issue Feb 5 - Feb 10 (Week 7) All existing modules will be properly tested to ensure full test coverage, fixing any issues encountered and writing new integration test for new codes and will be tested and ensuring that all work as expected improving and writing new integration test for new feature Improve the data flow for continually importing new uploads [B]-7 July 12 - August 17 (Week 8 ) * Each endpoint will be tested with different loads to see it’s stress level and impRove it’s performance, * Using Capybara to test the server rendered section of the test suite an tested end to end using the systems flow and ensuring all parts work toghether as expected. 26 - 2 (Week 9 ) Run end to test to ensure Existing iintermittent test failures are resolved Write a guide to assist developers in navigating and diagnosing issues in failing tests Implement a more intuitive and easy to understand reporting strategy for error logs and where exactly the error is from 4-9 (Week 10 ) Increase the JavaScript/JSX statement coverage to 90% 11-16 (Week 12 ) *Continue monitoring the system platform to ensure all test pass properly and are effective and handle new code Wrap up the research Code cleanup for submission == Participation I intend to use the project’s slack channel as the main communication channel and also through emails, as per the mentor’s convenience. I’ll equally github as the main means of contributing code where I will push commits to my own clone of the repository. I’ll be using GitHub’s issue tracker for feature requests and bugs and communicating through Phabricator task, I would equally help other contributors and users solve their issues and aid the process of reviewing my Pull request by writing good and understandable commit and pull request messages. =About Me == Education I am a software engineering graduate from the University of Buea, set to graduate this December. During my studies, I gained proficiency in Python and Rust, test driven development, which enabled me have a strong knowledge software development. I was introduced to and began contributing to free and open-source software during my sophomore year, and I have continued ever since. The open-source community provides a collaborative and welcoming environment where I can practice and improve my skills without bias or limitations. I am particularly passionate about learning and ensuring that everyone has access to free, quality education. Contributing to Wikimedia and the Wiki Education Dashboard allows me to support this initiative in my own small way == How did you hear about this program? I learned about Outreachy from a mentor who has contributed to wikimedia through Outreachhy and GSOC over the years and suggested it was a great opportunity for me to learn and apply my skills in an industry project. I have applied to Outreachy for five times , the first two times I was accepted but didn't go pass the contribution phase and the last 3 I wasn't accepted. == Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program? I have no other commitments as i am done with my degree program. I would like to spend time with my family from 24th of December to the 1st of January but I can accommodate any important task during this time. == Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program? I don't have any other commitments, I don’t have any summer plan other than Outreachy. The Outreachy project phase takes the highest position on my priority list == What does making this project happen mean to you? I strongly believe in contributing in my own way to improve the challenges I have faced, enabling others to benefit from my experiences, my first PR to the platform ran for over 50 minutes and it failed. I struggled to understand the reason for the failure, as I did not clearly identify where the error originated and found it difficult to interpret the error messages. This process took me an entire day to resolve after seeking help from my mentors, Sageross and Abishecks, who were very approachable and provided valuable guidance. on what the issue was. Over the course of the development i have realized other contributors also have this challenge and for a newcomer it is very overwhelming, So improving the test suites of the dashboard will help improve the developer experience and help newcomers better understand the error they are having and what is the possible cause and how to fix them. Furthermore, these improvements will enhance the overall performance of the dashboard, ensuring a seamless user experience and enabling students and instructors to maximize their use of the platform for education and knowledge transmission. From a professional point of view, I have recently begun learning Ruby on Rails as part of my development skill set. Additionally, I am focused on writing comprehensive and efficient tests to improve system performance, maintainability, and scalability. I believe this project will allow me to apply my knowledge, enhance my skills as a tester, and contribute to significant FOSS projects while gaining direct access to mentorship. == Past Experience I am passionate about performant system that are maintainable and scalable, having been passionate about Software development since my second year in university since then I have been working continuously on personal projects and some open source projects. I have always been interested in building software that are reliable and has practical scale implications, and Open source has provided me with the platform to do so. I make commits with clean commit messages and well structured Pull Requests, I believe this helps me communicate my understanding of the task and help my mentors in the review process = Coding Skills: == Programming Languages and Frameworks: Fluent in HTML, CSS, JavaScript, Ruby, Python Proficient in Ruby on Rails and experienced with Django (Python) and Java. Strong knowledge of OOP and MVC architecture. Experienced with front-end frameworks such as React, Next.js, and Redux. Proficient in testing tools: RSpec, Jest, and Capybara. Familiar with CI/CD practices and tools. Strong concepts of Git; can adapt to other version control tools if required. Good analytical and problem-solving skills. Effective communication skills for collaboration in a team. Understanding of Agile methodologies I have earned a great amount of experience with the codebase of the project. Also, I have made quite a few pull requests now and most of them have been merged. My contributions were focused towards writing unit test , fixing existing bugs, Here is a list of my contributions: == Wikimedia Contributions: https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5973 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5965 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5974 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5978 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5985 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5986 = Other Contributions == Unstructured Studio https://github.com/unstructuredstudio/zubhub/pull/736 https://github.com/unstructuredstudio/zubhub/pull/778

== Profile Information Name: Formasit Chijoh Fokunang Nickname: formasit Github: Formasitchijoh Email: formasitf@gmail.com/manoica2023@gmail.com Phone Number: +237-675-718-328 Location: Cameroon Time Zone: Cameroon (GMT + 1) == Meeting with mentors: I am reachable anytime through email, slack, and any communication channel GMT + 1, 6:00 AM to 10:00 PM = Synopsis == [WikiEducation Dashboard] Improve the Wiki Education Dashboard test suite Wiki Education Dashboard is a Ruby on Rails application that provides server-rendered fronted and contains a with a mixed React and Redux. It provides tracking and statistics for hundreds of thousands of editors on Wikipedia and other Wikimedia wikis.The Dashboard codebase uses a comprehensive suite of Ruby tests, including unit and feature tests, to maintain functionality.However, the current test suite is fails often, taking approximately 35 minutes to run (on GitHub CI), and is overall fairly fragile, with intermittently failing tests .The focus will be on identifying and improving quality and performance of the test suite, optimizing execution times, and increasing test coverage. Strategies such as parallelizing tests, and refactoring slow tests will be employed to achieve a more reliable and performant platform. Improving the Dashboard test suite will drastically improve the developer experience and making the platform performant and scalable == Mentors Sage Ross(@Ragesoss), Sulagna Saha(@saha23s) = (In Progress) == Deliverables 1. Identifying and fix all test that fail intermittently 2. Establish a test suite that passes 20 consecutive runs on CI 3. Refactor, rewrite and improve code quality and test coverage of areas of the code holes in test coverage and write test for untested LOC 4. document test case that can evolve for future reference == Implementation Details The Major scope of this project will focus on the ruby rspec test suite, for the ruby on rails backend which contain unit tests of individual class files as well as browser-driven feature (ie, integration) tests that interact with both the client-side UI and the server-side behavior, hence improving this section will greatly affect the performance of the entire test suite. The primary focus will be evaluating the test suite and its recent CI logs to identify intermittently failing tests, their causes, and tests that significantly contribute to long execution times and proper evalution of external API that the system interacts with. The project will also target areas of the codebase with gaps in test coverage and LOC with unwritten test , rewriting both the tests and underlying code as needed === STEP-I The current API of the system currently through error intermittently, * The first step will be to, * Run unit test each test for the different controllers, models and services in isolation to ensure it works as expected *Identify any patterns of failures in the test, * Identify the cause of the failure and document them, * Features that utilize third party Api like the LiftWing Api, ReferenceCounter APi, Commons Wiki, WwikiApi, often fail intemittenly, due to at least some of these problems, * The LiftWing API has different responses than what the specs were written around. * These third party endpoint will be tested under different condition to analyze it response and update existing to cover the response gotten from this endpoint RSpec test and code that use these endpoint. * These endpoint will be tested, to identify its’s interactions with the system and Why it fails * Currently the the CI/CD pipeline takes approximately 30 to 35 minutes to complete, this is relatively slow for development purposes, * Recent Sentry logs and development logs will, be reviewed to identify the different failure, and how they have evolved overtime, * Identify any pattern and dependencies. Using the most slowest apI request and test that are identified by the test suite, a timer will be used to identify the time that each of the requests takes and how identify how to optimize them and improve the performance. * I am currently working on issue of writing comprehensive test for the javascript and ruby test suite and from the issue that was raised here i have been going through all the failures that have come up during the contribution stage and am currently fixing them, i ill continue to do so until outreachy result declaration and all through the bonding phase === STEP-I After proper analysis of the entire test suite and identifying the different causes of intermittent failures and their causes , The project will employee automation testing strategy that will range from * updating existing unit test to fix and accommodate breaking changes and write new unit test to improve the test coverage for the lines of code with unwritten test * Update test for external API and ensure existing test are written around the recent responses that are returned by the external APi and ensure all features that unilizes them use the appropriate format * After analysis of the current failures it noticed that major section of the test suite that posses an issue are with the revision, articles and course that uses the LiftWing API and the ReferenceCounters of the articles, each of these models controllers and request test case will be reevaluated to improve the find issue * All existing modules will be properly tested to ensure full test coverage, fixing any issues encountered and writing new integration test for new codes and will be tested and ensuring that all work as expected improving and writing new integration test for new feature * Each endpoint will be tested with different loads to see it’s stress level and impRove it’s performance, * Using Capybara to test the server rendered section of the test suite an tested end to end using the systems flow and ensuring all parts work toghether as expected. * Using Sentry logs, test suites will be improves to reduce test run and equally optimize test performance. * create new test Data configurations and ensure existing once are improved to work === STEP-III * Run end to test to ensure Existing iintermittent test failures are resolved * Write a guide to assist developers in navigating and diagnosing issues in failing tests * Implement a more intuitive and easy to understand reporting strategy for error logs and where exactly the error is from == Future Goals: Will be implemented if all above-mentioned milestones are achieved and completed successfully and approved by the mentors, also desired to be taken up after Outreachy. *Increase the JavaScript/JSX statement coverage to 90% *Continue monitoring the system platform to ensure all test pass properly and are effective and handle new code === Timeline === October 29 - November 26: * Continue making contributions to the Wikieducation Dashboard === November 26 - December 9 * Community bonding period === December 9 - December 14 (Week 1 ) * Begin with the user research to identify further areas of improvements in the existing test suites * The first step will be to run unit test each test for the different controllers, models and services in isolation to ensure it works as expected and identify any patterns of failures in the test, identify the cause of the failure and document them, === December 16 - Jan 5 (Week 2) * Features that utilize third party Api like the LiftWing Api, ReferenceCounter APi, Commons Wiki, WwikiApi, often fail intemittenly, due with at least some of these problems, the LiftWing API has different responses than what the specs were written around. to different responses returned than what the Rspec expect, these third party endpoint will be tested under different condition to analyze it response and update existing to cover the reponse gotten from this endpoint Rpec and code that use these enpoint. These endpoint will be tested, to identify its’s interactions with the system and Why it fails === Jan 7 - Jan 12 (Week 3) * create new test Data configurations and ensure existing once are improved to work * Currently the the CI/CD pipeline takes approximately 30 to 35 minutes to complete, this is relatively slow for development purposes, recent Sentry logs and development logs will, be reviewed to identify the different failure, and how they have evolved overtime, and identify any pattern and dependencies. Using the most slowest apI request and test that are identified by the test suite, a timer will be used to identify the time that each of the requests takes and how identify how to optimize them. And improve the performance. === Jan 14 - Jan 19 * updating existing unit test to fix and accommodate breaking changes and write new unit test to improve the test coverage for the lines of code with unwritten test * Buffer time for previous weeks * Mid point feedback === Jan 21 - Jan 26 (Week 5) * Discuss how to improve exiting test and get feedback on the exisitng work * Update test for external API and ensure existing test are written around the recent responses that are returned by the external APi and ensure all features that unilizes them use the appropriate format *Using Sentry logs, test suites will be improves to reduce test run and equally optimize test performance. === January 28 - Feb 3 (Week 6 ) * After analysis of the current failures it noticed that major section of the test suite that posses an issue are with the revision, articles and course that uses the LiftWing API and the ReferenceCounters of the articles, each of these models controllers and request test case will be reevaluated to improve the find issue === Feb 5 - Feb 10 (Week 7) * All existing modules will be properly tested to ensure full test coverage, fixing any issues encountered and writing new integration test for new codes and will be tested and ensuring that all work as expected improving and writing new integration test for new feature === Feb 12 - Feb 17 (Week 8 ) * Each endpoint will be tested with different loads to see it’s stress level and impRove it’s performance, * Using Capybara to test the server rendered section of the test suite an tested end to end using the systems flow and ensuring all parts work toghether as expected. === Feb 26 - March 2 (Week 9 ) Run end to test to ensure Existing intermittent test failures are resolved Write a guide to assist developers in navigating and diagnosing issues in failing tests Implement a more intuitive and easy to understand reporting strategy for error logs and where exactly the error is from === March 4- March 9 (Week 10 ) * Increase the JavaScript/JSX statement coverage to 90% === March 11- March 16 (Week 12 ) *Continue monitoring the system platform to ensure all test pass properly and are effective and handle new code Wrap up the research Code cleanup for submission == Participation I intend to use the project’s slack channel as the main communication channel and also through emails, as per the mentor’s convenience. I’ll equally github as the main means of contributing code where I will push commits to my own clone of the repository. I’ll be using GitHub’s issue tracker for feature requests and bugs and communicating through Phabricator task, I would equally help other contributors and users solve their issues and aid the process of reviewing my Pull request by writing good and understandable commit and pull request messages. =About Me == Education I am a software engineering graduate from the University of Buea, set to graduate this December. During my studies, I gained proficiency in Python and Rust, test driven development, which enabled me have a strong knowledge software development. I was introduced to and began contributing to free and open-source software during my sophomore year, and I have continued ever since. The open-source community provides a collaborative and welcoming environment where I can practice and improve my skills without bias or limitations. I am particularly passionate about learning and ensuring that everyone has access to free, quality education. Contributing to Wikimedia and the Wiki Education Dashboard allows me to support this initiative in my own small way == How did you hear about this program? I learned about Outreachy from a mentor who has contributed to wikimedia through Outreachhy and GSOC over the years and suggested it was a great opportunity for me to learn and apply my skills in an industry project. I have applied to Outreachy for five times , the first two times I was accepted but didn't go pass the contribution phase and the last 3 I wasn't accepted. == Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program? I have no other commitments as i am done with my degree program. I would like to spend time with my family from 24th of December to the 1st of January but I can accommodate any important task during this time. == Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program? I don't have any other commitments, I don’t have any summer plan other than Outreachy. The Outreachy project phase takes the highest position on my priority list == What does making this project happen mean to you? I strongly believe in contributing in my own way to improve the challenges I have faced, enabling others to benefit from my experiences, my first PR to the platform ran for over 50 minutes and it failed. I struggled to understand the reason for the failure, as I did not clearly identify where the error originated and found it difficult to interpret the error messages. This process took me an entire day to resolve after seeking help from my mentors, Sageross and Abishecks, who were very approachable and provided valuable guidance. on what the issue was. Over the course of the development i have realized other contributors also have this challenge and for a newcomer it is very overwhelming, So improving the test suites of the dashboard will help improve the developer experience and help newcomers better understand the error they are having and what is the possible cause and how to fix them. Furthermore, these improvements will enhance the overall performance of the dashboard, ensuring a seamless user experience and enabling students and instructors to maximize their use of the platform for education and knowledge transmission. From a professional point of view, I have recently begun learning Ruby on Rails as part of my development skill set. Additionally, I am focused on writing comprehensive and efficient tests to improve system performance, maintainability, and scalability. I believe this project will allow me to apply my knowledge, enhance my skills as a tester, and contribute to significant FOSS projects while gaining direct access to mentorship. == Past Experience I am passionate about performant system that are maintainable and scalable, having been passionate about Software development since my second year in university since then I have been working continuously on personal projects and some open source projects. I have always been interested in building software that are reliable and has practical scale implications, and Open source has provided me with the platform to do so. I make commits with clean commit messages and well structured Pull Requests, I believe this helps me communicate my understanding of the task and help my mentors in the review process = Coding Skills: == Programming Languages and Frameworks: Fluent in HTML, CSS, JavaScript, Ruby, Python Proficient in Ruby on Rails and experienced with Django (Python) and Java. Strong knowledge of OOP and MVC architecture. Experienced with front-end frameworks such as React, Next.js, and Redux. Proficient in testing tools: RSpec, Jest, and Capybara. Familiar with CI/CD practices and tools. Strong concepts of Git; can adapt to other version control tools if required. Good analytical and problem-solving skills. Effective communication skills for collaboration in a team. Understanding of Agile methodologies I have earned a great amount of experience with the codebase of the project. Also, I have made quite a few pull requests now and most of them have been merged. My contributions were focused towards writing unit test , fixing existing bugs, Here is a list of my contributions: == Wikimedia Contributions: https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5973 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5965 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5974 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5978 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5985 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5986 = Other Contributions == Unstructured Studio https://github.com/unstructuredstudio/zubhub/pull/736 https://github.com/unstructuredstudio/zubhub/pull/778

== Profile Information Name: Formasit Chijoh Fokunang Nickname: formasit Github: Formasitchijoh Email: formasitf@gmail.com/manoica2023@gmail.com Phone Number: +237-675-718-328 Location: Cameroon Time Zone: Cameroon (GMT + 1) == Meeting with mentors: I am reachable anytime through email, slack, and any communication channel GMT + 1, 6:00 AM to 10:00 PM = Synopsis == [WikiEducation Dashboard] Improve the Wiki Education Dashboard test suite Wiki Education Dashboard is a Ruby on Rails application that provides server-rendered fronted and contains a with a mixed React and Redux. It provides tracking and statistics for hundreds of thousands of editors on Wikipedia and other Wikimedia wikis.The Dashboard codebase uses a comprehensive suite of Ruby tests, including unit and feature tests, to maintain functionality.However, the current test suite is fails often, taking approximately 35 minutes to run (on GitHub CI), and is overall fairly fragile, with intermittently failing tests .The focus will be on identifying and improving quality and performance of the test suite, optimizing execution times, and increasing test coverage. Strategies such as parallelizing tests, and refactoring slow tests will be employed to achieve a more reliable and performant platform. Improving the Dashboard test suite will drastically improve the developer experience and making the platform performant and scalable == Mentors Sage Ross(@Ragesoss), Sulagna Saha(@saha23s) = (In Progress) == Deliverables 1. Identifying and fix all test that fail intermittently 2. Establish a test suite that passes 20 consecutive runs on CI 3. Refactor, rewrite and improve code quality and test coverage of areas of the code holes in test coverage and write test for untested LOC 4. document test case that can evolve for future reference == Implementation Details The Major scope of this project will focus on the ruby rspec test suite, for the ruby on rails backend which contain unit tests of individual class files as well as browser-driven feature (ie, integration) tests that interact with both the client-side UI and the server-side behavior, hence improving this section will greatly affect the performance of the entire test suite. The primary focus will be evaluating the test suite and its recent CI logs to identify intermittently failing tests, their causes, and tests that significantly contribute to long execution times and proper evalution of external API that the system interacts with. The project will also target areas of the codebase with gaps in test coverage and LOC with unwritten test , rewriting both the tests and underlying code as needed === STEP-I The current API of the system currently through error intermittently, * The first step will be to runto, * Run unit test each test for the different controllers, models and services in isolation to ensure it works as expected and i *Identify any patterns of failures in the test, identify the cause of the failure and document them, * Identify the cause of the failure and document them, * Features that utilize third party Api like the LiftWing Api, ReferenceCounter APi, Commons Wiki, WwikiApi, often fail intemittenly, due withto at least some of these problems, the * The LiftWing API has different responses than what the specs were written around. to different responses returned than what the Rspec expect, t * These third party endpoint will be tested under different condition to analyze it response and update existing to cover the response gotten from this endpoint RpecRSpec test and code that use these endpoint. * These endpoint will be tested, to identify its’s interactions with the system and Why it fails * Currently the the CI/CD pipeline takes approximately 30 to 35 minutes to complete, this is relatively slow for development purposes, r * Recent Sentry logs and development logs will, be reviewed to identify the different failure, and how they have evolved overtime, and i * Identify any pattern and dependencies. Using the most slowest apI request and test that are identified by the test suite, a timer will be used to identify the time that each of the requests takes and how identify how to optimize them. A and improve the performance. * I am currently working on issue of writing comprehensive test for the javascript and ruby test suite and from the issue that was raised here i have been going through all the failures that have come up during the contribution stage and am currently fixing them, i ill continue to do so until outreachy result declaration and all through the bonding phase === STEP-I After proper analysis of the entire test suite and identifying the different causes of intermittent failures and their causes , The project will employee automation testing strategy that will range from * updating existing unit test to fix and accommodate breaking changes and write new unit test to improve the test coverage for the lines of code with unwritten test * Update test for external API and ensure existing test are written around the recent responses that are returned by the external APi and ensure all features that unilizes them use the appropriate format * After analysis of the current failures it noticed that major section of the test suite that posses an issue are with the revision, articles and course that uses the LiftWing API and the ReferenceCounters of the articles, each of these models controllers and request test case will be reevaluated to improve the find issue * All existing modules will be properly tested to ensure full test coverage, fixing any issues encountered and writing new integration test for new codes and will be tested and ensuring that all work as expected improving and writing new integration test for new feature * Each endpoint will be tested with different loads to see it’s stress level and impRove it’s performance, * Using Capybara to test the server rendered section of the test suite an tested end to end using the systems flow and ensuring all parts work toghether as expected. * Using Sentry logs, test suites will be improves to reduce test run and equally optimize test performance. * create new test Data configurations and ensure existing once are improved to work === STEP-III * Run end to test to ensure Existing iintermittent test failures are resolved * Write a guide to assist developers in navigating and diagnosing issues in failing tests * Implement a more intuitive and easy to understand reporting strategy for error logs and where exactly the error is from == Future Goals: Will be implemented if all above-mentioned milestones are achieved and completed successfully and approved by the mentors, also desired to be taken up after Outreachy. *Increase the JavaScript/JSX statement coverage to 90% *Continue monitoring the system platform to ensure all test pass properly and are effective and handle new code === Timeline === October 29 - November 26: * Continue making contributions to the Wikieducation Dashboard === November 26 - December 9 * Community bonding period === December 9 - December 14 (Week 1 ) * Begin with the user research to identify further areas of improvements in the existing test suites * The first step will be to run unit test each test for the different controllers, models and services in isolation to ensure it works as expected and identify any patterns of failures in the test, identify the cause of the failure and document them, === December 16 - Jan 5 (Week 2) * Features that utilize third party Api like the LiftWing Api, ReferenceCounter APi, Commons Wiki, WwikiApi, often fail intemittenly, due with at least some of these problems, the LiftWing API has different responses than what the specs were written around. to different responses returned than what the Rspec expect, these third party endpoint will be tested under different condition to analyze it response and update existing to cover the reponse gotten from this endpoint Rpec and code that use these enpoint. These endpoint will be tested, to identify its’s interactions with the system and Why it fails === Jan 7 - Jan 12 (Week 3) * create new test Data configurations and ensure existing once are improved to work * Currently the the CI/CD pipeline takes approximately 30 to 35 minutes to complete, this is relatively slow for development purposes, recent Sentry logs and development logs will, be reviewed to identify the different failure, and how they have evolved overtime, and identify any pattern and dependencies. Using the most slowest apI request and test that are identified by the test suite, a timer will be used to identify the time that each of the requests takes and how identify how to optimize them. And improve the performance. === Jan 14 - Jan 19 * updating existing unit test to fix and accommodate breaking changes and write new unit test to improve the test coverage for the lines of code with unwritten test * Buffer time for previous weeks * Mid point feedback === Jan 21 - Jan 26 (Week 5) * Discuss how to improve continuous new uploads Keeping up withexiting test and get feedback on the ongoing researchexisitng work * Update test for external API and ensure existing test are written around the recent responses that are returned by the external APi and ensure all features that unilizes them use the appropriate format *Using Sentry logs, test suites will be improves to reduce test run and equally optimize test performance. === January 28 - Feb 3 (Week 6 ) * After analysis of the current failures it noticed that major section of the test suite that posses an issue are with the revision, articles and course that uses the LiftWing API and the ReferenceCounters of the articles, each of these models controllers and request test case will be reevaluated to improve the find issue === Feb 5 - Feb 10 (Week 7) * All existing modules will be properly tested to ensure full test coverage, fixing any issues encountered and writing new integration test for new codes and will be tested and ensuring that all work as expected improving and writing new integration test for new feature Improve the data flow for continually importing new uploads [B]-7 July=== Feb 12 - August 17Feb 17 (Week 8 ) * Each endpoint will be tested with different loads to see it’s stress level and impRove it’s performance, * Using Capybara to test the server rendered section of the test suite an tested end to end using the systems flow and ensuring all parts work toghether as expected. === Feb 26 - 2March 2 (Week 9 ) Run end to test to ensure Existing iintermittent test failures are resolved Write a guide to assist developers in navigating and diagnosing issues in failing tests Implement a more intuitive and easy to understand reporting strategy for error logs and where exactly the error is from 4-9=== March 4- March 9 (Week 10 ) * Increase the JavaScript/JSX statement coverage to 90% 11-16=== March 11- March 16 (Week 12 ) *Continue monitoring the system platform to ensure all test pass properly and are effective and handle new code Wrap up the research Code cleanup for submission == Participation I intend to use the project’s slack channel as the main communication channel and also through emails, as per the mentor’s convenience. I’ll equally github as the main means of contributing code where I will push commits to my own clone of the repository. I’ll be using GitHub’s issue tracker for feature requests and bugs and communicating through Phabricator task, I would equally help other contributors and users solve their issues and aid the process of reviewing my Pull request by writing good and understandable commit and pull request messages. =About Me == Education I am a software engineering graduate from the University of Buea, set to graduate this December. During my studies, I gained proficiency in Python and Rust, test driven development, which enabled me have a strong knowledge software development. I was introduced to and began contributing to free and open-source software during my sophomore year, and I have continued ever since. The open-source community provides a collaborative and welcoming environment where I can practice and improve my skills without bias or limitations. I am particularly passionate about learning and ensuring that everyone has access to free, quality education. Contributing to Wikimedia and the Wiki Education Dashboard allows me to support this initiative in my own small way == How did you hear about this program? I learned about Outreachy from a mentor who has contributed to wikimedia through Outreachhy and GSOC over the years and suggested it was a great opportunity for me to learn and apply my skills in an industry project. I have applied to Outreachy for five times , the first two times I was accepted but didn't go pass the contribution phase and the last 3 I wasn't accepted. == Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program? I have no other commitments as i am done with my degree program. I would like to spend time with my family from 24th of December to the 1st of January but I can accommodate any important task during this time. == Will you have any other time commitments, such as school work, another job, planned vacation, etc, during the duration of the program? I don't have any other commitments, I don’t have any summer plan other than Outreachy. The Outreachy project phase takes the highest position on my priority list == What does making this project happen mean to you? I strongly believe in contributing in my own way to improve the challenges I have faced, enabling others to benefit from my experiences, my first PR to the platform ran for over 50 minutes and it failed. I struggled to understand the reason for the failure, as I did not clearly identify where the error originated and found it difficult to interpret the error messages. This process took me an entire day to resolve after seeking help from my mentors, Sageross and Abishecks, who were very approachable and provided valuable guidance. on what the issue was. Over the course of the development i have realized other contributors also have this challenge and for a newcomer it is very overwhelming, So improving the test suites of the dashboard will help improve the developer experience and help newcomers better understand the error they are having and what is the possible cause and how to fix them. Furthermore, these improvements will enhance the overall performance of the dashboard, ensuring a seamless user experience and enabling students and instructors to maximize their use of the platform for education and knowledge transmission. From a professional point of view, I have recently begun learning Ruby on Rails as part of my development skill set. Additionally, I am focused on writing comprehensive and efficient tests to improve system performance, maintainability, and scalability. I believe this project will allow me to apply my knowledge, enhance my skills as a tester, and contribute to significant FOSS projects while gaining direct access to mentorship. == Past Experience I am passionate about performant system that are maintainable and scalable, having been passionate about Software development since my second year in university since then I have been working continuously on personal projects and some open source projects. I have always been interested in building software that are reliable and has practical scale implications, and Open source has provided me with the platform to do so. I make commits with clean commit messages and well structured Pull Requests, I believe this helps me communicate my understanding of the task and help my mentors in the review process = Coding Skills: == Programming Languages and Frameworks: Fluent in HTML, CSS, JavaScript, Ruby, Python Proficient in Ruby on Rails and experienced with Django (Python) and Java. Strong knowledge of OOP and MVC architecture. Experienced with front-end frameworks such as React, Next.js, and Redux. Proficient in testing tools: RSpec, Jest, and Capybara. Familiar with CI/CD practices and tools. Strong concepts of Git; can adapt to other version control tools if required. Good analytical and problem-solving skills. Effective communication skills for collaboration in a team. Understanding of Agile methodologies I have earned a great amount of experience with the codebase of the project. Also, I have made quite a few pull requests now and most of them have been merged. My contributions were focused towards writing unit test , fixing existing bugs, Here is a list of my contributions: == Wikimedia Contributions: https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5973 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5965 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5974 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5978 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5985 https://github.com/WikiEducationFoundation/WikiEduDashboard/pull/5986 = Other Contributions == Unstructured Studio https://github.com/unstructuredstudio/zubhub/pull/736 https://github.com/unstructuredstudio/zubhub/pull/778