Skip to content
This repository was archived by the owner on Jul 5, 2025. It is now read-only.

Commit 2576e2b

Browse files
authored
Web UI (#8)
1 parent 25efb88 commit 2576e2b

File tree

194 files changed

+7195
-37
lines changed

Some content is hidden

Large Commits have some content hidden by default. Use the searchbox below for content that may be hidden.

194 files changed

+7195
-37
lines changed

.github/workflows/build-ga.yaml

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -37,8 +37,11 @@ jobs:
3737
- name: Lint check
3838
run: ./gradlew ktlintCheck
3939

40-
- name: Build all targets
41-
run: ./gradlew assemble
40+
# - name: Build all targets
41+
# run: ./gradlew assemble
42+
43+
- name: Build JVM targets
44+
run: ./gradlew shadowJar
4245

4346
- name: Run JVM tests
4447
run: ./gradlew jvmTest

.github/workflows/build-pr.yaml

Lines changed: 5 additions & 2 deletions
Original file line numberDiff line numberDiff line change
@@ -37,8 +37,11 @@ jobs:
3737
- name: Lint check
3838
run: ./gradlew ktlintCheck
3939

40-
- name: Build all targets
41-
run: ./gradlew assemble
40+
# - name: Build all targets
41+
# run: ./gradlew assemble
42+
43+
- name: Build JVM targets
44+
run: ./gradlew shadowJar
4245

4346
- name: Run JVM tests
4447
run: ./gradlew jvmTest

CONTRIBUTING

Lines changed: 174 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,174 @@
1+
# Contributing guide
2+
3+
[//]: # (Inspired by github.com/nayafia/contributing-template)
4+
5+
#### Thank you! 💚
6+
7+
First off, thank you for considering contributing to this project. It's people like you that make Code Stats such a great tool.
8+
9+
Now let's get down to business.
10+
11+
### Why these guidelines?
12+
13+
Following these guidelines helps to communicate that you respect the time of the developers managing and developing this open source project.
14+
In return, they should reciprocate that respect in addressing your issue, assessing changes, and helping you finalize your pull requests.
15+
16+
Without this guide, we're all just making assumptions – the authors of this tool don't like that.
17+
18+
### What <u>does</u> this tool need?
19+
20+
Code Stats is an open source project for a reason, and we love to receive contributions from our community — you!
21+
There are many ways to contribute, from writing tutorials or blog posts, improving the documentation, submitting
22+
bug reports / bug fixes / feature requests, or even writing new code which can be incorporated into Code Stats itself.
23+
24+
The more work you do, the more karma you get.
25+
26+
### What <u>doesn't</u> this tool need?
27+
28+
Please, **do not** open issues, bug reports, feature requests and other work requests if the same already exists.
29+
Check whether the issues page on GitHub already has your request, and see if the existing issue list can help you.
30+
Stack Overflow is also worth considering if you're customizing the tool for your needs.
31+
32+
Please, **do not** open new pull requests at random without creating an issue first.
33+
It is important that we don't start making changes to the tool without prior consent from the maintainers.
34+
This goes even for documentation fixes and other cosmetic improvements.
35+
36+
37+
# Ground Rules
38+
39+
### Setting expectations
40+
41+
#### Maintainer and contributor responsibilities:
42+
43+
* Ensure cross-platform compatibility for every change that's accepted
44+
* This is best done through the continuous integration (CI) pipelines
45+
* Ensure that code that goes into the project meets all requirements set by the project configuration
46+
* CI pipelines are there to verify, just in case
47+
* Create issues for any changes and enhancements that you wish to make
48+
* Discuss things transparently and get feedback
49+
* Follow the best practices for the given platform, unless the project is configured to do differently
50+
* When not sure, follow the project's codebase to understand the maintainer behavior
51+
* Keep feature versions as small as possible, preferably one new feature per version
52+
* The project uses [semantic versioning](https://semver.org)
53+
* Maintainers are generally busy, and they do open-source work on a voluntary basis
54+
* Please treat maintainers as volunteers and not your employees
55+
* Be welcoming to newcomers and encourage diverse new contributors from all backgrounds
56+
* See the [Python Community Code of Conduct](https://www.python.org/psf/codeofconduct/) for reference
57+
58+
### Your First Contribution
59+
60+
Unsure where to begin contributing to Code Stats?
61+
You can start by looking through the [list of open issues](https://github.com/milosmns/code-stats/issues).
62+
We will try to categorize the issues using labels and tags, so you'll be able to use labels and tags to filter.
63+
While not perfect, number of comments on an issue is a reasonable proxy for impact a given change will have.
64+
65+
#### For people and bots who have never contributed to open source projects before:
66+
67+
Working on your first issue? Here are some resources to get you started with Pull Requests (PRs):
68+
69+
* [EggHead's **How-To**](https://app.egghead.io/playlists/how-to-contribute-to-an-open-source-project-on-github)
70+
* [MakeAPullRequest's **How-To**](https://makeapullrequest.com)
71+
* [FirstTimersOnly's **How-To**](http://www.firsttimersonly.com)
72+
73+
You're not feeling ready to make your changes? Then feel ready to ask for help. 🤓 Everyone is a beginner at first!
74+
75+
For example, if a maintainer asks you to "rebase" your PR, they're saying that a lot of code has changed outside of your work,
76+
and that you need to update your git branch so it's easier to merge.
77+
78+
#### 🙄 &nbsp; <font color="#A02070">WhY dIs BaD cOdE? HoW tO wOrK?</font>
79+
80+
Well… look, we get it. Software evolves and 💩 happens over time.
81+
Technology stacks change, popular libraries lose their appeal, and best practices transform.
82+
Despite the best efforts of maintainers, legacy code and technical debt often accumulate, not by choice but by necessity.
83+
84+
In the case of Code Stats, the project has traversed several phases:
85+
86+
1. Wrapped GitHub's original "contributors" page in an `<iframe>` with minor edits
87+
2. Transitioned to an enterprise export from GitHub to Big Query
88+
3. Advanced further with SQL export to Google Sheets for enhanced visualization
89+
4. Implemented a JavaScript bot operating on live data with no storage
90+
5. Adopted TypeScript, running inside Firebase's functions-based nodes
91+
6. Developed a Python _Command Line Interface_ (CLI) for BigQuery and Firebase
92+
7. Enhanced the CLI with _some_ offline storage
93+
8. Utilized Kotlin, integrating Python CLI modules, still with an offline storage
94+
9. Embraced pure HTML5 and JavaScript, communicating with Firebase Python functions
95+
10. **Current open-source versions (Nov 2023)**
96+
97+
Different features and modules were created using diverse languages and approaches to problem-solving, as well as programming paradigms.
98+
Consequently, some Kotlin code resembles JavaScript, some JavaScript code mimics Python, and certain tooling scripts bear similarities to Python's behavior.
99+
100+
A unified tech stack for all project layers would be optimal (maybe). However, extensive refactoring currently prevents this consolidation.
101+
But hey, here's the good news – the project now relies on **only two** tech stacks: Kotlin for CLI/data processing/backend and HTML5 with JavaScript for the frontend.
102+
103+
Additionally, it's important to note that [Chat GPT](https://openai.com/blog/chatgpt) contributed to parts of this code.
104+
[GitHub's Copilot](https://github.com/features/copilot) also played a significant role in code generation.
105+
Due to these specialized tools, coding styles and complexities vary across features.
106+
107+
Ending on a positive note – the project is now open-source and welcomes contributions for refactoring and cleanup!
108+
109+
110+
# Getting started
111+
112+
### How to submit contributions
113+
114+
The general how-to:
115+
116+
1. Check out this contributing guide in full
117+
1. Note the custom license that Code Stats has today
118+
1. Create your own fork of the repository
119+
1. Make the changes in your fork
120+
* For obvious reasons, make sure to include tests with every product change
121+
1. When you finally like the changes and think the project could use them:
122+
1. Make sure you have followed the code style for the project
123+
1. Open a new pull request indicating that you are ready for a review
124+
125+
126+
# How to report a bug
127+
128+
### Security considerations
129+
130+
If you believe that you have found a security vulnerability, **DO NOT** open an issue disclosing it. Try to reach out to the maintainers directly through their GitHub account pages.
131+
132+
In order to determine whether you are dealing with a security issue, ask yourself these two questions:
133+
134+
* Can I access something that's not mine, or something I shouldn't have access to?
135+
* Can I disable something for other people?
136+
137+
If the answer to either of those two questions are "yes", then you're probably dealing with a security issue. Note that even if you answer "no" to both questions, you may still be dealing with a security issue – so if you're unsure, just reach out to one of the maintainers in private to discuss it.
138+
139+
### General bugs
140+
141+
When filing a new bug issue, make sure to answer these five questions:
142+
143+
1. What version of Code Stats are you using?
144+
1. What operating system and processor architecture are you using?
145+
1. What did you do when you saw the issue?
146+
1. What did you expect to see?
147+
1. What did you see instead?
148+
149+
150+
# How to suggest a feature or enhancement
151+
152+
### General requests
153+
154+
We should aim to to provide small, robust tooling for our users.
155+
156+
If you find yourself wishing for a feature that doesn't exist in Code Stats, you are probably not alone. There are others out there with similar needs. Many of the features that we have today have been added because the users saw the need, whether internally or externaly (post open-sourcing).
157+
158+
To make a new request, simply open a new issue on our issues page on GitHub, and in it describe the feature you would like. Make sure to include what you'd like to see, why you need it, and how it should work in detail.
159+
160+
161+
# Code review process
162+
163+
### General contributions
164+
165+
The maintainers look at Pull Requests (PRs) on a regular basis. We can't say exactly how often, but normally it's multiple times per month.
166+
As each PR must include a link to the issue it is addressing, it should be clear to the maintainers what they're looking at.
167+
168+
After PR feedback has been given, we expect responses within two weeks. After two weeks, we may decide to close the PR if it isn't showing any activity.
169+
170+
### Code, commit message, labeling, and other conventions
171+
172+
For now, there are no strict rules. In general, we use imperative language for commit messages (as that's the industry standard).
173+
174+
If there are new style rules, they will be included in this section as they appear.

0 commit comments

Comments
 (0)