moja-global / about_moja_global Goto Github PK

Make an issue template or make a label. It should probably be a feature under .github.
To be decided.

Describe how we are communicating and why it is not optimal.
As discussed in the last meeting moja global would love to have an active community of opensource developers and new contributors. Let's discuss some ways we as an organisation can drive more new contributors. Please feel free to add suggestions below or provide feedback.

Describe the solution you'd like

• Creating simple and easy to begin with contributing guidelines : To be completed in GSOD under @Patamap guidance
• Creating first-timer-only or good for newcomer issues : Creating issues that are easy to solve following specific first-timers-only issue template (example: - publiclab/plots2#8094) (https://www.firsttimersonly.com/ (great resource please check out))
• Reaching out on social media inviting new opesourcers/contributors: Creating short and simple posts to invite fellow connections to contribute by linking some good for newcomer issues in the post
• Adding moja global to first-timer-only issue featuring websites:
  Add ourselves to this list - https://github.com/MunGell/awesome-for-beginners
  Add ourselves to the github good first issue tracker - https://github.com/topics/good-first-issue by adding 'good first issue as a topic' by following https://help.github.com/en/articles/classifying-your-repository-with-topics

Issue formats exist for bugs, features, science, feedback but not for admin, documentation, comms, etc. It would be good to add these options.

@Tlazypanda has a first draft full diagram of how the pieces of mojo global fit together and how to work together; we need to make a public version of that document and add it to our documentation.
https://hackmd.io/@itm2017004/ByX5A1fgP

What to do
Propose a diagram in the Moja global README.
Investigate and agree on the final diagram in the Moja global README.
Create a public version of the diagram and content.
Submit a pull request to about moja global.
Show diagram in the Moga global README

Why do it
Moja global has many projects with many contributors. We want contributors to spend time working on valuable areas of Moja global that help the project. By investing time and effort into the project, we want to reward that time and effort with accepted contributions. To accept meaningful contributions, we need to make it more clear how Moja global fits together and how to work together. This is part of internal communication.

Refer tolink to the map of current moja global GitHub repositories and the content within them.
The proposal documentation is here
These are created by https://github.com/sabitarao.

@Tlazypanda @gmajan

What does the current documentation state?

To Be Completed
Where is this stated?

About_moja_global/Governance/Contribution-Criteria.md

Why do you want to improve the statement?
Most of new contributors can get a lot of information from contribution criteria but this markdown file is not completed.

Proposed statement
I can rewrite and fill all the criteria which is neccesary for first time contribution.

Additional info
could you look into this issue @Tlazypanda

Describe how we are communicating and why it is not optimal.
Currently, the moja global instances are capitalized in welcome bot config.

Describe the solution you'd like
Moja global instances should be decapitalized in welcome bot config.

Welcome bot is
Specification is needed.
Issue for adding config in import repo: @Tlazypanda
Config file: Create PR for versionabout moja global (import repo) @Tlazypanda
@gmajan Should we add this to other repositories (FLINT,FLINT.example etc)??

Refer to

1. how to setup the bots as admin https://docs.google.com/document/d/1B1k2kRpAdtl9U8v-ze-uO56m8rldIuiAG1nQoZRpyDI/edit?usp=drivesdk

Proposed to add/update the content in https://github.com/moja-global/About_moja_global/blob/master/CONTRIBUTING.md

1) Add "Table of contents" link to able to see the overview in once and able to select the one that wanted to read.

1. Code of Conduct
2. FAQ and General Questions
3. How To Get Credit for Your Contribution?
4. How to Contribute Code?
5. How to Report Bugs, Provide Feedback or Request Features?
6. How to Review & Contribute to Science Design?
7. How to Suggest UI/UX Improvements?
8. How to Contribute Translations?
9. Are There Other Ways of Contributing?

2) Add 4 Subjects: "Contribute what?", "Ground rules", "Getting started" and "Code review process"

3) Add "Contribute what?"

There are different ways to contribute to a project. Some ways to contribute are…
Writing code.
Submitting bug reports/feature requests
Improving documentation
Writing tutorials posts

4) Add subject "Ground rules"

Ground rules
These ground rules are the basic responsibilities for contributing to the project.

DO's
DO run unit tests before submitting a pull request
DO create issues first for major changes/enhancements you want to make
Discuss things transparently first and get community feedback
DO keep each pull request to one feature/bug fix.
If you want to submit multiple things, submit multiple pull requests
DO write unit tests for new features
DO write good commit messages <add link https://tbaggery.com/2008/04/19/a-note-about-git-commit-messages.html"72
DON'Ts
DON'T commit changes to files irrelevant to your pull request.

5). Add subject "Getting started"
Working on your first pull request? Learn how from this free series. How to Contribute to an Open Source Project on GitHub

1. Fork the project to your GitHub account.
2. Create changes in your fork.
3. Run unit tests once you're done.
4. Send a pull request to our repo.

6) Add subject "Code Review Process"
The core team of Moja Global reviews pull requests on a weekly basis. The core team may vary – see an updated list in the
<add the link that shows who are the maintanent in each repo)

Expect a response on new pull requests within five business days? (Mon-Fri). If you don't receive any feedback, please follow up with a new comment!6

@gmajan @Tlazypanda May I have your opinion, please for these CONTRIBUTING page?
Refer to #63

Describe the solution you'd like
Currently the pull request is not tested on whether it is following cpp style conventions and other code quality checks. Static analysis tools such as cppcheck and clang-tidy can help us check pull requests and have better code maintainability in the future.

Describe alternatives you've considered
As per discussion with @kaskou we need to develop our own testing github actions to allow customization ahead. - https://github.com/Tlazypanda/cpp-clang-check is currently in preliminary stages and has been pre-released as a github actions on github marketplace.

We need to study the following existing tools to ensure this action has all these features -
https://github.com/smay1613/cpp-linter-action
https://github.com/deep5050/cppcheck-action

Issues:
A clear and concise description of what the problem is. Ex. When I reach this point, I cannot [...]
Adopt a code of conduct (Contributor Covenant, https://www.contributor-covenant.org?) to set clear expectations for acceptable and unacceptable behavior in Moja global projects

Solution:
Agree or write a code of conduct to set clear expectations and guidelines for contributor behavior in Moja global projects, have a general idea of how to handle violation reports should they ever happen.

Background:
Having a code of conduct for an open-source project is important. A company or organization has a human resources department and expectations for how employees are to behave, but an open-source project does not. Setting clear expectations for what behavior is appropriate or not is important, and also assures confidence in contributors that their experience will be positive.

See GitHub's open-source guide for a more in-depth explanation of the value of a code of conduct.

Comlete a proof of concept for CI/CD tools in both FLINT.Example (cmake/C++) and FLINT.Data_Preprocessing (Python) repositories.

Steps proposed:

1. Research/Find a free CI tool. Looking into norms for open source (if any).
2. Needs to integrate with FLINT cmake tests, or suggest new method to run unit/integration tests
3. Test process on repos suggested about
4. Plan implementation to other repos

CMake/FLINT:

FLINT has some unit tests built into each library. CMake can be set to run these on build and will have some integration with lots of CI/CD tools (i.e cmake: RUN_UNIT_TESTS_ON_BUILD)

Python:

Not sure what is available to integrate unit tests into CI/CD. Will need to be investigated.

Need the simple instruction for those topics due to missing.

1. Create a feature branch for development.

2. Create a tag ( semantic versioning rules).

3. Deploying the application.

Describe the bug
When a new issue is created it does not get its label automatically.

To Reproduce
Create an issue

Expected behavior
When issue is created, it is automatically assigned the correct label: bug, features, comms, docs, etc

Screenshots
NA

Operating Environment:
GitHub

Additional context
NA

The community website will have the following features:-

1. Information about our Workflow: The workflow will consist of the series of actions a new contributor can begin with i.e - claiming a first-timers issue, followed by creating a first-timers issue for someone else and helping others by providing feedback and reviewing their pull requests.
2. List of First-timer only issues: The list of issues specifically meant for first-timers or new contributors.
3. List of Stale issues: The list of issues that haven’t been worked on for a long period of time and hence are available to be picked by contributors.
4. List of Contributors: The list of contributors who have so far contributed to Moja Global repositories.
5. Recent Contributors: The list of contributors who have recently contributed to Moja Global repositories.
6. Links to join chat forums: Information and links to join the Slack com2munity to resolve their queries and have further discussions on the projects.

Refer to https://docs.google.com/document/d/1MoSOYdlUFV2ar9e_rG4P43ucwoMUO2mTQ9pjetRGdaY/edit# from @Tlazypanda: Location of the community website. See the example here; https://code.publiclab.org/

Is your feature request related to a problem? Please describe.
@zulipbot is a GitHub workflow bot application for the Zulip organization and its repositories. Written in Node.js, the bot manages issues and pull requests in the repository in order to create a better workflow for Zulip contributors.

zulipbot's purpose is to work around various limitations in GitHub’s binary permissions and notifications systems to create a better workflow for our contributors. It allows anyone to perform issue triage (self-assigning and labeling issues), not just the core contributors trusted with full write access to the repository (which is the only model GitHub supports). Additionally, zulipbot monitors the activity of issues and pull requests, notifying contributors about new merge conflicts, continuous integration build results, inactivity, and more.

Describe the solution you'd like
We can install Zulipbot to our organization repositories by following this installation guide here. This will allow issues to get assigned to whoever comments first and also unassigned if there is inactivity for a given period of time reducing the work for maintainers.

See the instruction here: https://docs.google.com/document/d/1B1k2kRpAdtl9U8v-ze-uO56m8rldIuiAG1nQoZRpyDI/edit

Additional context
Screenshots showing the bot in action: -

Is your feature request related to a problem? Please describe.
Adding a pull request template will make it easier for contributors and maintainers to review the code since they will first have to meet the checklist provided in the pull request template to be eligible for the review.

Describe the solution you'd like
Add pull request template markdown file to .github folder.

This bot will automatically add new Issues or Pull Requests to a Project board based on specially formatted Cards in each Column of a Project.
We will customize the rules for moving Issues between Columns.

@Tlazypanda,

Actions are

1. Configure Project-bot.
2. Create doc: Zulipbot and Project-bot.

Describe the bug
Inconsistency of Copyright dates across the webpages in the moja-global official website, i.e. 2021 on mobile devices and 2020 on desktop devices.

To Reproduce
Steps to reproduce the behavior:

1. Go to https://moja.global/
2. Click on the different sidebars.
3. Scroll down to bottom of the page.
4. Look for the inconsistency of dates between Copyright © 2021 and Copyright © 2020 on different pages on when viewed from desktop.

Expected behavior
The date should update automatically and should be independent of any device and manual intervention.

Screenshots

Operating Environment:

• Desktop
• OS independant

Additional context
The problem can be easily fixed by adding a new Date().getFullYear() JS function in place of static text under desktop view.

Describe what you are trying to do and why it is not optimal.
I would like to join your project. Can you please add me?

Specification is needed.

Refer to GSOD proposal task
https://docs.google.com/document/d/1MoSOYdlUFV2ar9e_rG4P43ucwoMUO2mTQ9pjetRGdaY/edit

@gmajan Refer to #69

How to make a new GitHub repository workflow best practices?

1. Repository creation (name conventional)
   #41

2. Configure repository (automatic licence, readme, config lable (in org leve?l), etc)
   @Tlazypanda, please create a new issue with the spec of configuration repos.

3. Updated document: Repository creation.

4. Set up useful labels, #44

5. Updated document: Set up useful labels
   https://docs.google.com/document/d/1Yxyu9rfrRc94s3e3lhKFjmcOnudsqrs-fqxYsSJ9QAc/edit#

What does the current documentation state?
Copy and paste the text currently in the documentation. If you want improve graphs or photos, please provide a screenshot of the original.

Where is this stated?
Provide additional information about the location where you have copied the above statement from.

Why do you want to improve the statement?
Please explain why the statement needs to be updated. This can be because it is confusing, incorrect, spelling/grammatical errors, etc.

Proposed statement
Please propose how you would rewrite the statement. If you have a precise proposal, please make the changes and open a pull-request.

Additional info
Add any useful information here.

Propose the simple table with Repo, Description, and Maintainers. So all contributors can understand the summary of projects and maintainers contact.

See the proposal below, => This proposal is no longer used anymore. The maintenance team can be found in the readme of each repo.

Unaware of reading the guideline/basic information for a newcomer although the read the guide is located on each page of moja global.

Solution
The small icon shows as a recognizing on each page for a newcomer for guiding him/her to the right place to read before starting to work with Moja global.
@gmajan @Tlazypanda

Hi!

I think that the current contribution guidelines can be vastly simplified.

Many of the guides like How-to-Report-Bugs.md, How-to-Provide-User-Feedback.md, How-to-Request-a-New-Feature.md can all be reduced into a single line:

To report bugs, provide feedback, request new features, etc., please create a new issue by choosing an appropriate template from here.

We can also merge the more important guides like How-to-Contribute-Code.md and How-to-Contribute-Review-Science-Design.md into CONTRIBUTING.md. This will make the guidelines much easier to read.

Simple and easy to understand contribution guidelines can not only promote contributions but can also help us "create inclusive communities" (as reported by GitHub's 2017 Open Source Survey).

Please, let me know what you think. I'd be delighted to submit a PR implementing these suggestions 🙂

The purpose of CI is here, #72

Actions are

1. Set up CI communication in SLACK. Done.
   https://app.slack.com/client/T1G1M5HPF/C015F595D0W/thread/D014MSKDFGW-1592806920.001400

2. Testing the FLINT (ask the question/engage Jim and Max) to get the gap and able to write the specification.
   https://github.com/moja-global/testarea/issues

3. Set up server.
   @leitchy @mfellows @malfrancis

4. Set up CI code/tool

5. Updated document: Use continuous integration (CI).

@Tlazypanda item 2 - item 6 will need the new issues for each item.

Goal: Set up continuous integration (CI) to build new pull requests against FLINT projects.

Why CI?
CI is important for a project because it prevents simple mistakes or oversights making it into a production codebase. Effective test cases can be written to hook into any of the CI platforms available, such as TravisCI, CircleCI, and others.

CI is helpful for advanced contributors (especially in a small project) because of limited development time and the ease of making mistakes. It happens. It's a safeguard to help prevent mistakes from entering "production" code.

CI is helpful for new contributors because it provides instant feedback if a pull request breaks the project or not. A contributor can see feedback and a stacktrace of what went wrong so they can fix their issue or ask for specific help if needed (instead of waiting for a maintainer to review the PR and give that feedback).

Details
There are general test cases available for many programming languages. Those could be set up easily. More advanced CI would encourage contributors to write test cases into the code, and then CI platforms could execute those test cases.

Each FLINT project will likely need its own unique CI configuration, If developer bandwidth is low, some projects that are more "publicly visible" should be prioritized for CI coverage.

Expected Outcome
Pull requests to a FLINT project are tested and verified to build successfully before a maintainer reviews a new contribution; this helps prevent bad code making it into the code base and provides immediate feedback to new contributors to fix oversights or mistakes.

There seem to be slightly different versions of the participation agreements and charter that have the same date. The website has versions that are slightly different in formatting. It would be good to check and update.

Actions are

1. Cleanup/Maintanent SLACK; bring to Steering technical committee; 12 August, 2020.
2. Configuration SLACK for the newcomer, etc. - Done refer to ....

@Tlazypanda, can you please provide the specification for the configuration of SLACK for newcomer?

Summary: Establish a documentation platform for hosted documentation about Moja Global projects.

Background: Effective documentation is critical in technical projects – open source or otherwise. However, it's especially helpful for Moja Global because of the small team size and need to engage with the open-source community.

Better documentation for MojaGlobal means…

1. New contributors/contractors learn the pipeline/software quicker
2. Design decisions are better documented (less time back-tracking)
3. Enables other contributor-oriented documentation (e.g. issue / PR templates, see a xxx?)
4. Easier to tell a story (e.g. Opensource.com, see xxxx?)

Details
Choosing a platform should be based on what is most intuitive and easiest to maintain for the team. A popular platform is ReadTheDocs, which uses a Python-based toolchain. Thus, it also makes it an especially fantastic tool for Python projects, but it is still great for any programming language regardless.
see the example: https://magicbox.readthedocs.io/en/latest/#

Or Just the doc is good option. See the example: https://sabitarao.github.io/mojaglobal/

Expected Outcome
Better documentation means a better experience for people to contribute to our projects; enables us to bring new people into the community easier and also provide reference points for various design decisions in the future (i.e. why we did something the way we did)

Describe the bug

The issue labels on the repos are inconsistent and this may cause problems later hence they need to be updated.

Proposed Solution
Using copy-github-labels-cli tool we will standardise the labels across multiple repositories.

@gmajan @Tlazypanda @Patamap

Cleanup/Maintanent SLACK in order to easy and transparent for everyone to use it.

Need spec.

Part of EPIC #43

What does the current documentation state?
Info on why FLINT and how to install FLINT is in ReadMe of .github which contains only info on how to work with moja global organisation.

Where is this stated?
In Readme

Why do you want to improve the statement?
Too much info in the wrong place. Nobody wants to ready that much.

Proposed statement
Move info to the FLINT repo

Clear Communication though members play a big role to help everyone to work effectively together. Summarize all internal communication and investigate if there is needed any update.

How to do it

1. Identify what are we doing for internal communication and the effectiveness2 of the current one.
2. The proposal the update the internal information.
3. Evaluate.
4. Implemented

Why do it
When people come wanting to contribute, we need to help guide their first steps. Simple and easy access information and let them explore the "newcomer issues" tasks are great ways to introduce how we work in mojo global by giving them a simple guideline and manageable area to focus on or work. These internal communications get both newcomers and existed teams more comfortable with the project and could edge someone towards contributing bigger things.

@gmajan @Tlazypanda

https://help.github.com/en/articles/about-community-profiles-for-public-repositories

Describe the bug
When I try to add the labels for time required: the labels are missing

To Reproduce

@all-contributors please add @juliancabezas for code.

Is your feature request related to a problem? Please describe.
Welcome is a simple way to welcome new users based off maintainer defined comments.

The 3 plugins it combines with are new-issue-welcome(Comment to be posted to on first time issues) , new-pr-welcome(Comment to be posted to on PRs from first time contributors in your repository) and first-pr-merge(Comment to be posted to on pull requests merged by a first time user).

Describe the solution you'd like
We can setup Welcome bot by adding the GitHub App to our organization repositories and configuring .github/config.yml according to the content of the messages we want.

This will make the new contributors feel welcomed and at ease in interacting with the community.

Additional context
Screenshots that depict the Welcome bot in action:

Able to select the reviewers directly on the issue page. It means 1, 2, 3 can review issues/new ideas to agree and approve together.

What does the current documentation state?
To explain how to use issue and project board with labels.

Where is this stated?
In google doc.

Why do you want to improve the statement?
Everyone can work in the same way of working.

@gmajan: please see the updated labels in the link below, that can be used for organization level.
Refer to the document there,
https://docs.google.com/document/d/1Yxyu9rfrRc94s3e3lhKFjmcOnudsqrs-fqxYsSJ9QAc/edit#

What does the current documentation state?
https://github.com/moja-global/.github/wiki/What-Is-a-moja-global-Project%3F
This page has missing links to:
mobilize the necessary resources
join the projects
submit project idea

What does the current documentation state?
We are using an unwritten naming convention for the repositories. As far as I know, we use . to indicate a sort of sub-directory and _ to connect words of 1 title.
The top directory indicates the initiative the directory is under: e.g. GSoC so people know that adding to these repos might interfere with deliverables.
If there is no initiative, then the repo is operational and thus open.
The second layer is the tool the repo is under. FLINT for most repos but not all.
Next is the name of the repo

If this is indeed how we work, it would be good to document this and make sure the existing names are in line.

Where is this stated?
Nowhere yet

Why do you want to improve the statement?
If we have a clear naming system, contributors feel at ease to make new repos and they can quickly understand what repos are for.

Proposed statement
Follow an agreed naming system

Additional info
None

Describe what you are trying to do and why it is not optimal.
With the CI framework setup with python (click, pytest, github workflows), we now need to determine a good way to implement CD of the project.

Possible solution:
The solution should be able to deploy different build for python readily. Currently thinking about using Jekins and Google.

Describe alternatives you've considered
Jenkins seems quite consistent looking into various open source alternative for frameworks to deploy on, like AWS etc.

Additional context
Looking for any additional ideas for implementation and resources to use @Tlazypanda

Document on the Tech Stack/Architecture at the high level.

See the current diagram in Lucichart here, https://app.lucidchart.com/invitations/accept/2aef6458-ed34-48bf-a13e-ef877878430e. Many thanks to @leitchy.

The next steps are requested.

As agreed with @gmajan, the one repo should have only one board in order to track all development issues and documents issues in one board.

Actions are

1. Set up board rules (simple, no backlog, duplicated approved/done).
2. Document.

Related to #59

Refer from #65. @Tlazypanda
Updating here - greetbot setup on slack for

• Direct message when a newcomer joins.
• Channel message for when newcomers join #gsoc-general
  To be updated/changed acc to the convenience of other slack members.
  Can take this up in the next meeting

The result of the msg for greetbot
Hello @new_user_name !:wave: Welcome to moja global!:sparkling_heart:
Moja global fosters an open and welcoming environment for all our contributors.:cherry_blossom: Please adhere to our Code Of Conduct and be respectful during all communications.
If you are new here and looking for channels to join, here are a few recommendations:
#gsoc-general - For all GSOC related announcements, queries and discussions
#newcomers - For all newly joined members of the community. Feel free to introduce yourself!
#random - A place for non-work related jibber-jabber
It is highly encouraged to have discussions in specific channels instead of in #general.
Moja global is delighted to have you here :) Hope you have a great time here

@Tlazypanda, thanks for a new feature of Greetbot on Slack. for channels right now I have only set it up on gsoc-general as a demo. Let me know where else to incorporate and what changes are to be done with the content? l
@gmajan,

This issue acts as a means to house all the Technical Steering Committee related discussions that need to be put forward in the meetings by @gmajan .

The actions items to be discussed is referenced through this Google Doc here :https://docs.google.com/document/d/176jTXrgles5IoMrTOSb3FrSwwhG0RTrXrHzDkojLk6E/edit

The minutes of meetings is referenced through this Google Doc here:- https://docs.google.com/document/d/1EMXmBlBNa7qzy8NQ6O9MWV1nzBxgWGAIlpI4MZlrwzo/edit?usp=drivesdk

If there's any suggestion that you would like to be put forward to the Technical Steering Committee please contact @gmajan.

Thanks you!

Come up with 3-5 bugs or simpler tasks to work on any Moja Gobal project especially main core projects like FLINT, Modules, About Moja Global; clearly label them as "good first issues" and leave them open for new contributors to try working on

How to do it
Across core projects, come up with shortlist of small / quick improvements or fixes wanted, but not urgently needed
File new issues/update existing ones to explain easier tasks
Explain the problem, clearly explain the deliverable / desired result
Label these tasks clearly with a "new comer" label
Keep them open for new contributors or team members to work on (core / active contributors shouldn't take these tasks)

Why do it
When people come wanting to contribute, we need to help guide their first steps. Simple or "easyfix" tasks are great ways to introduce a new contributor to your project by giving them a small, manageable area to focus on or work. This supports a marginal improvement to your project but also delivers purpose to someone navigating your code for the first time. These tasks get them more comfortable with the project and could edge someone towards contributing bigger things. But it's easier to start with a smaller piece first.

@leitchy @malfrancis @kaskou @mfellows @gmajan @RobboW

Set up board rules and configuration board (simple, no backlog, duplicated approved/done).
@gmajan.

Those instructions for moja global are missing, therefore we need those documents below,

1. Update issue and pull request
2. Adding labels
3. Updating project boards
4. Making pull requests
5. Reviewing pull requests