Developer Guidelines and Coding Style ****

[Shoalsteed]

https://geti2p.net/en/get-involved/guides/dev-guidelines

Issues

Monitor (Gitlab issues link) for new issues you can help with.

New developers should start by fixing a bug. When you have a fix, attach your patch to the issue and add the keyword 'review-needed'. Do not close the issue until it's been successfully reviewed and you've checked your changes in. Once you have done this smoothly for a couple of issues, you can follow the regular procedure below.

Close an issue when you think you have fixed it. The project does not have a testing department to verify and close issues. If you are not sure that you have fixed it, close it and add a note saying "I think I fixed it, please test and reopen if it's still broken". Add a comment with the dev build number or revision and set the milestone to the next release.

[Shoalsteed]

[Shoalsteed]

Changed copy to reflect shift to Gitlab issues. Removed some text that sounds a bit personal. Replaced "we" with "the project"

[luciewho]

@Shoalsteed what does the ____ in "Monitor ____ for new issues you can help with." stand for?

[luciewho]

I think some of the other copy needs adjusting for this page such as:

[luciewho]

Wondering if it's worth cutting some of this down or organizing the information so it appears less dense/wall of text

[luciewho]

Call them Bugs when happening but when they are in Gitlab they are called Issues. In the Router Console Bugs change to "Report an Issue"

[Shoalsteed]

The overall tone of this page needs significant work.

[Shoalsteed]

Guidelines For Contributing to I2P Core Development

The following instructions and suggestions apply to the main development branch i2p.i2p. Guidelines for other branches, plugins, and external apps may be substantially different. Check with the appropriate developer for guidance.

Please participate in development discussions and support on IRC, zzz.i2p, and i2pforum.i2p. Meetings are held on the first Tuesday of the month to discuss roadmap progress.

Test the latest builds, report and fix issues, review documentation and perform code reviews. Be aware of the current release cycle. Adhere to release milestones such as feature freeze, tag freeze, and the checkin deadline for a release.

Developers are available on IRC #i2p-dev.

I have consolidated the Basic Guidelines and Community into one opening paragraph and renamed it.

[Shoalsteed]

Wondering if it's worth cutting some of this down or organizing the information so it appears less dense/wall of text

yes, I will remove cruft

[Shoalsteed]

Release Cycle The release cycle is 6-12 weeks. The following are the approximate deadlines within a typical 8-week cycle. Actual deadlines for each release are set by the lead developer after consultation with the full team.

[Shoalsteed]

Coding Style Coding style throughout most of the code is 4-spaces for indentation. Please do not use tabs. Please do not reformat code. If your IDE or editor wants to reformat everything, configure your editor appropriately. Watch for places where the coding style is different. Emulate the style in the file you are modifying.

[luciewho]

Here is the link for Gitlab Issues: https://i2pgit.org/i2p-hackers/i2p.i2p/-/issues

Also available on Figma under Support > Developer Resources: https://www.figma.com/file/RBaCbkTXWS3FMDGAtHcIjc/Information-Architecture---I2P-Website?node-id=210%3A3164