Private or Public?

Right now, your repository is set to private.

You can change the visibility of a repository to Private or Public at any time, but there are some things you should know.

Private Repositories

If your repository is private, then the only people who can see your code are the collaborators that you've invited.

Private repositories also aren't free. The price depends on how many collaborators have access to any given repository, but the base price is $7 per month for unlimited private personal repositories.

You might want this repository to be private if it has sensitive information, or depending on the software's license.

Public Repositories

In public repositories, anybody can see your code. All of the millions of open source repositories on GitHub are public, too!

Licenses, code of conduct, other files become even more important when the world can interact with you and your code. There are many benefits to this, but it's also a large responsibility. Keep in mind that once a repository is public and open source, there are certain implications about keeping it public, depending on the license chosen.

It's important to note that public does not equal open source! The license associated with code determines whether or not it is open source.

I won't respond to this issue, just close it when you are done!

When i am launching the prog-o-meter, its asks do i have a meter, in both situations i should input username, and i can leave it empty and submit(or close this window), and there will be no error, and i think its some kind of error, may be its better to check if field is empty and give a notification to user that this field is empty, and also how i describe early its will work when i close this window, i think its better to return to window (with buttons "do i have meter" and other) in this kind of situation, if you think that its is necessary, i can do it

Elheffe80 pointed out an unused variable (i) in a for loop on line 130. I will fix this as soon as possible, and go through and make the same doesn't occur elsewhere in the code too.

First timers only
This means that this issue have been determined a good place to start for someone who have not been contributing to open source before. Let us know how we can help you get started or if you have any questions. We would really love for you to join us

This is a sub-part of issue #30, but I think it would be a very nice start.
Wnen the user clicks the "1 more day" button upon completing their last day, let's display a nice celebratory image on the canvas.

Here is a suggestion for how to solve it:

• Find a nice celebratory image (remember to find something with a creative common license or similar, so we are allowed to use it - or if you are creative, you could draw/create one for the project!). Store it in the same folder, as where you store the prog-o-meter.py on your computer
• Every time the user click "1 more day", check if this was there day 100
  • If this was the day 100, display image on canvas (you will have to decide on what the best location is, depending on the size of the image) Here is the Tkinter guide on images, which might be helpful

As always, the above is only a suggestion, and there a probably many other ways to solve the same problem, so feel very free to take your own approach
Let me know if you have any questions, or would like any help getting started :)

Nice idea you have here, but you may want to seriously consider supporting/moving to python 3, especially because this is a new project and you are early on in development.

Since I don't have experience working with databases, and the program was simple enough from start, the data needed to be stored (the completed days), is just stored in a .txt file locally on the user's computer. If anyone is interesting in implementing a more traditional database, that would be awesome. It would be especially useful, if we are gonna progress with this issue #31

Creating documentation

GitHub Pages is a powerful tool that creates a static web page for GitHub repositories. GitHub Pages looks for an index.html or index.md file, but will also use a README.md file as the home page for the web page.

You can choose to have GitHub Pages look at the master branch, the gh-pages branch, or the /docs directory of the master branch.

⌨️ Activity: Enabling GitHub Pages for Documentation

1. Create a /docs/index.html file in this repository.
2. In the Settings tab of this repository, scroll to "GitHub Pages". Enable GitHub Pages with a source as /docs.
3. Using static web technologies, you can create documentation in this file that will be automatically served as a free web page.

I won't respond to this issue, just close it when you are done!

Step 2: Prepare the project

Working with Binary files

In general, there are two types of files: text files and binary files.

Text files, like most code files, are easily tracked with Git and are very lightweight.

However, binary files like spreadsheets, presentations with slides, and videos don't work well with Git. If your repository already has some of these files, it's best to have a plan in place before you enable Git version control.

You could choose to remove the binary files, or use another tool like git-lfs (Git Large File Storage). We won't get into detail on how to set up git-lfs in this course, but we will talk about .gitignore files next, which are key to protecting your code from becoming bloated with binaries.

Add a .gitignore

As mentioned above, there are files you won't want to store in Git. In addition to avoiding binaries, you will also want to keep build artifacts out of your version controlled code. As we convert your project to a Git repository, it should only include the source code necessary to build or compile your project.

To do this, you will create a file in your current project named .gitignore. When you switch over, Git will use the .gitignore to determine which files and directories should not be tracked under version control.

A .gitignore file should be committed into your repository in order to share the ignore rules with any other users that interact with the repository.

Since the files to be ignored are dependent on the language you are using, the open source community has contributed some great templates for .gitignore files in the github/gitignore repository.

⌨️ Activity: Prepare your repository

1. Remove any binary files from your repository.
2. In your local environment, create a .gitignore file. Use a template or create your own.

When you are finished, close this issue. I will open a new issue with the next steps. 🎉

Watch below for my response

🤖 I'm waiting for you to close this issue before moving on.

This is not related to prog-o-meter directly, but is a great resource!!

https://www.humblebundle.com/software/python-dev-kit-bundle

Not affiliated, nor an affiliate link. However, there is a LOT of great stuff in there, so spend the $20 and get everything. Totally worth it for the training videos, software, and everything.

Because the strings don't wrap, I am sometime missing part of a text (c.f. screenshot)

I was able to fix the issue by changing line 233:

self.canvas.create_text(self.CANVAS_WIDTH/2, 20, text = "Good to see you again! Please enter your name")`

to something like this.

self.canvas.create_text(self.CANVAS_WIDTH/2, 20, width = self.CANVAS_WIDTH-20, text = "Good to see you again! Please enter your name")

Let me know if you like this fix and I'll apply it to all the strings that might be impacted by this issue.

We could maybe implement a button, that opens up a text-input-box, that lets user input the numbers of days they have already progressed.

This would be useful if:

• The user starts using the prog-o-meter, but have been doing their challenge for a while (i.e. user is on day 12 of their #100DaysofCode challenge, and wanna starts using the prog-o-meter. Instead of having to click the "1 more day!" button 12 times, they can manually input the number of days they have already completed)
• The user forgets to update the prog-o-meter for a couple of days, and don't wanna have to input all the days, by clicking the "1 more day!" multiple times.
• It might also be useful if the user have accidentally clicked the "1 more day!" button too many times, but we should figure out if it would be better to rather add an "WOOPS!" button, to let the user undo a click on the "1 more day!" button. (We should therefor consider whether it should only be allowed to use the manual input days button to add numbers of days that are larger than current number of days - I would like to hear what other people think)

Suggestion:

• Create a button that is added to the Tkinter canvas (You can look at the code for the submit buttons in the prog-o-meter.py file, to get inspiration on how to make a button - however, you will have to add information about the placement of the new button)
• When the user click the button, a new window should open up, with a text field where user can type their current number of days, and click submit (You can take inspiration from the UsernameGUI in the prog-o-meter.py file, for inspiration on how to create a simple window that takes user input in text format) Remember to convert the input to an integer, if it isn't automatically taken as an integer - you should also check if the number the user provided is between 0 and self.GOAL (which is the number of days the user is trying to reach.) If the input is not a number or it is smaller than 0 or greater than self.GOAL, we should show probably print an error message "input not understood", or something similar, and then the user will have to click the button and try again - you don't need to worry about this to begin with, we can start by assuming the user will behave well, and then add a check later.
• When the user have clicked submit, we should update the variable self.days to hold the new number of days, and we need to store the new number of days in the user's file. We can use the update_days_file function to do this.
• When we have stored the new number of days, we need to update the prog-o-meter, this can be done by calling the function progress()

As always the above is just a suggestion, and there are probably many other problems to solve the problem. Feel free to do it your way.
Let me know if you have any questions, or want some help getting started, by posting a comment below.

We could make a feature where the user could set a goal for themselves (either day-to-day ("Tomorrow I will finish commenting the foo.py file", "Tomorrow I will do the video-lesson on example.com"), or longer term "Goal for day 20: Have made a static webpage about my dog".

The user would then see their goal when opening the prog-o-meter the next day, and be able to click a button showing they have reached their goal (and we could find a way to celebrate it, see for example #29 or #30).

We could possibly store all past, reached goal somehow, and give the user the possibility to look back on them.

What do people think? Any suggestions on how to best do this?

Protected Branches

When you look in the Settings tab of your repository, you'll see Branches on the left side. Here, you can choose to enable something called Protected Branches.

What are Protected Branches?

Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. These branches can also be protected by requiring pull requests to have at least one approved review before they can be merged.

You might want to use protected branches if you're working on a team, you have CI tests enabled, or in any case where you want to be sure that the code that gets merged into the master branch meets a certain set of requirements.

If you'd like to enable protected branches, go ahead and do so now, and then close this issue.

Not sure what settings to enable? Check out this article that goes into more detail about the settings for protected branches.

I won't respond to this issue, just close it when you are done!

We should make a user guide for how to use the prog-o-meter

Since this project was started as a one-person-thing, I have not had someone review the initial code, that we start out with.
It would be super helpful, both to me, and to the entire project, if someone would review that current code.

Currently, once you chose if you're a new user or an existing one, on the next screen you need to click in the text box to start typing. Then click on submit to go to the next screen.

1. We could easily use the focus_set() method to activate the text box automatically so you don't have to click on it anymore. This is a one-liner self.text_entry.focus_set() after line 258.
2. I was also wondering if there is a way to make it possible to hit 'Enter' to go to the next screen? In addition to the Submit button.

Step 3: Make the move

Having a project already stored locally enables you to move it to GitHub rather quickly. The following activity provides instructions to move your local project to GitHub using various tools. Select the tool you are most comfortable with and get importing 😄.

⌨️ Activity: Moving your local project

1. In the Code tab of this repository, copy the URL shown under Quick Setup.
2. Follow the instructions below based on what tool you'd like to use locally.

Watch below for my response

🤖 Once you push your project to GitHub, I'll provide the next steps in your journey.

We could add a new button which opens a new window, which lets the user personalize their prog-o-meter.

For example, we could let the user choose which color they wan't completed days to have (currently set to blue), and what color they wan't the new day they add to have (currently set to green).

We could also let them change the number of days of their goal (e.g. #50DaysofCode, #500DaysofCode). We will have to control that the number of days of their goal is greater than 0 (we can't display negative days). We might also have to have a max number of days of the goal, since it will have to fit (and look nice), on the canvas.

We could also let user add a line of text to the window, with their motivation (e.g." My motivatio: I code to change my career", "My motivation: learning everyday", etc.)

When updates are made by clicking the "personalize" button, they should be reflected in the window, and probably also saved so they will remain next time user uses program (Currently we store user data in a .txt file, but maybe someone have ideas for how to do it differently?)

Feel free to comment with other suggestions for things user's should be able to personalize.

If user clicks they have existing meter, but there is no such meter, program crashes without warning. Should probably implement some sort of pop-up box telling them they need to slap themselves with a fish or check their spelling & try again.

Although your repository is currently private, you might want to review the different licenses available, especially if you are thinking about open sourcing your project. Licenses aren't normally used in private or closed source applications, but they are very important for public or open source project, because they set the rules for how others are allowed to use, change, and contribute to your project.

⌨️ Activity: Adding a License

1. Read this documentation about having a License
2. Add a License to this project using the GitHub Flow

I won't respond to this issue, just close it when you are done!

Hi, my name is Heff, and I am completely new to programming, git, and yada yada yada. I was drawn to this project from reddit (https://www.reddit.com/r/learnpython/comments/8dsn6o/beginner_python_projects_on_github/ ) through a search for:
is:open is:issue language:python label:"good first issue"
and found the encouragement of the day (which I want to work on). In reading through all the documentation, I saw a few little things that needed some cleaning up. I have forked the project so I can clean those up while I familiarize myself with tkinter and everything else. I look forward to learning everything about this project- seems like a REALLY awesome way to cut my teeth!

We need a way to handle if the user say that they are returning user (currently the option "I already have a meter"), but then gives a name that does not exist.

• One solution could be to check if the user exists (i.e. if there locally is a .txt file with the name provided by the user).
  • If such a file does not exist, we can display some text saying something like "Woops, we cannot find you. Please make sure you give us the same name, as last time you used to prog-o-meter" (maybe this text should be in red, to draw more attention) (and the user then types their name again)

We could maybe also find a way for the user to go back to the StartGUI screen, if they pressed "I already have a meter!" by accident.

In order to avoid that the user accidentally clicks "1 more day" twice in the same day, and then have to manually reset their count correctly, we could add a limit - either a fully enforced limit, or we could have have a pop-up if the user clicks the button again the same day, that asks "You already clicked once today, are you sure you meant to click again?"
We could store a timestamp for the latest click, and compare the current time of the new click against it, to see if the new click happens on the same day?
What do the rest of you think about this?

If we do move forward with this, we should probably not add it to the program until we have issue #24 implemented. But if someone is interested, they can still go ahead an work on it.

Step 5: Project settings

In your repository, you will see a Settings tab on the right-hand side of the navigation, after Code, Issues, Pull Requests, and other categories. I've opened a milestone to track each of the settings issues.

Project visibility

Repositories can be "owned" by individual user accounts or by organization accounts. If this repository is currently under your own user account but you'd like it to be owned by your organization, don't worry. You can change repository ownership.

Repositories can also be private or public.

A private repository can only be seen by those who are collaborators, administrators, or owners. Permission has to be explicitly granted.

A public repository has code, issues, and pull requests that can be seen by anyone on the internet. Public repositories should always have licenses, so it's clear if others are able to use the project or code in any way. Just because a repository is public doesn't mean that anyone can make changes, though - only collaborators, administrators, or owners can do that.

Add collaborators

If you want to give others permission to edit the code in your repository, you will need to add them as collaborators. In the Settings tab of your repository, find the Collaborators tab on the left navigation. Then, you can invite others to your repository.

Protected branches

Protected branches ensure that collaborators on your repository cannot make irrevocable changes to branches. These branches can also be protected by requiring pull requests to have at least one approved review before they can be merged.

If you want to know more about protected branches, check out this documentation.

Integrations/services

Integrations are tools and services that connect with GitHub to complement and extend your workflow.

Integrations can be GitHub Apps, OAuth Apps, or anything that utilizes GitHub APIs or webhooks. For more information, see "About integrations" in the GitHub Developer documentation.

You can find an integration to install or publish your own integration in GitHub Marketplace and Works with GitHub.

All done?

When you're done, close this issue. I'll open new issues in this repository with your next instructions.

Watch below for next steps!

Your repository has no Code of Conduct.

Having a Code of Conduct is really important, even in private repositories. Instead of re-writing the wheel, I want to point you to some of the best instructions around.

⌨️ Activity: Add a Code of Conduct

1. Read this documentation about having a Code of Conduct
2. Add a Code of Conduct to this project using the GitHub Flow
3. Close this issue when you're done

I won't respond to this issue, just close it when you are done!

I have written too long summaries (first line in docstrings). Need to stay within 72 chars, as prescribed by PEP257, which ensures the ability to use automatic indexing tools. I will shorten up the docstrings soon, unless someone else have a go at it before I can get to it.

The prog-o-meter window could probably look much prettier than it currently does. Maybe it should have another size, maybe the "1 more day!" button should have another location, maybe we should use different fonts/sizes/colors for the text, etc.

I am by no means a good designer, and if someone want's to work on making the window look nicer, that would be much appreciated.

It would also be helpful if someone wanted to just sketch out a suggested design, that someone else can then implement

First timers only
This means that this issue have been determined a good place to start for someone who have not been contributing to open source before. Let us know how we can help you get started or if you have any questions. We would really love for you to join us

We have two buttons in the first window the user opens. Right now they have different width, and that looks a little silly. It would be great if we could set them to have the same width. This can be done by adding the width parameter to each of the radio button objects.

Here is documentation for Tkinter radiobuttons. Check out the config part, and look for width.
I don't know what the ideal width would be, It will require some experimentation.
The two radiobuttons are declared in the input_buttons(self) function, which belongs to the StartGUI class.
If someone have ideas for better text for each button, that is even clearer to the user, this is also very welcome.

Let us know if you would like to work on this issue, and have any questions or would like some help.

Writing a log is often considered an important part of the #100DaysofCode challenge. In a log the user would write some text everyday, about their work that day.
We could implement a feature (and maybe let the user decide themselves, whether to enable/disable it), which open a window with a text-input-field each day when they click the "1 more day!" button. The user can then write their log directly through the prog-o-meter program, and we could store it locally in a .txt file on their computer

Things to consider:

• Should it only be possible to add text to log when clicking the "1 more day!" button, or should a user who wanna update their log multiple times a day, have an opportunity to do that.
• Should the user provide the headline (i.e. day 4), or should the program do that automatically.
• Make sure that we don't overwrite current text, when inputting new

Your repository has no description! Let's add one.

⌨️ Activity: Adding a project description

1. Access the Code tab of your project.
2. Click the Edit button located on the right side of the screen (above the green Clone of download button).
3. Enter a description for your project in the Description field.
4. (Optional) If you have a website related to your project you can add it in the Website field.
5. Click the Save button.

I won't respond to this issue, just close it when you are done!

We should make sure that if a user closes a window, then the subsequent windows should not be opened.

There are 3 classes, which each launches a Tkinter window. If one of them is closed by the user (by clicking the red X button in the upper right corner), the next window(s) should not be launched.
This means that clicking the red X button on any of the 3 windows, should be considered closing down the entire prog-o-meter program

1. StartGUI (here the user indicates if they are a new or returning user)
2. UsernameGUI (here the user provides their name, so we can either create a new prog-o-meter for them, or retrieve their saved information, and make a new one for them)
3. ProgressGUI (here the prog-o-meter is shown)

Below the current line of text displayed in the prog-o-meter window stating how many days the user have left before they reach the goal, we should also display a line of text stating the end-date, i.e. the date on which they will reach their goal.

This requires that we calculate the end-date based on the current date + The number of remaining days of challenge (self.GOAL-self.days)

We should also make sure to update the the add_day method (belonging to the ProgressGUI class), so that when it is called, this line of text is updated. (Most likely the end-date will be the same, if the user is progressing at the "normal" speed. However, if they have not been progressing for one or more days, and then add a new day after their "hiatus", we should calculate, and display the new end-date)

Suggestion: You can add the new code to the canvas_layout method belonging to the ProgressGUI class. For inspiration on how to do it, check out the assignment of self.countdown_text in canvas_layout method belonging to ProgressGUI.
Maybe the python module datetime (https://docs.python.org/3/library/datetime.html) can be used to calculate which date it will be, x days from today.

Set up Integrations

There are many services that integrate with GitHub. These integrations provide specialized solutions to take your software and workflow to the next level.

You can search for and browse integrations in GitHub's Marketplace, and on this "Works with" site.

You might have some integrations set up to sync with your project on another platform, or maybe you are integrating manually. Go ahead and connect these now, and then close this issue when you're done.

I won't respond to this issue, just close it when you are done!

We could implement a feature, where we print an encouragement to the user every day when they click the "1 more day button". Encouragements could be stuff like "Nice job!", or "Keep on learning", etc. or they could my motivational quotes, or something else nice.
Encouragements could either be displayed as pop-up window, or just as a Tkinter text element above or below the prog-o-meter

Suggestion: Look at the current file, to see how text is displayed on a Tkinter canvas. To change encouragement each day, we can either have a set sequence (i.e. certain text to display on day one, two, three, etc.), or we can just have a collection of the texts/quotes we want to display, and randomly select one each time the "1 more day!" button is clicked

Making Collaboration Easier

In public repositories specific files can help the community contribute to an Open Source project. Even though you are using a private repository doesn't mean you project can't benefit from those same files. These files inform and enable contributors to make contributing easier.

I've opened up issues for each one of the items that you should take action on, and started a milestone to help you keep track of them.

To continue with best practices for moving to GitHub, close this issue. Don't worry, the milestone will remain open so you can return to it later.

Watch below for my next response

🤖 I'm waiting for you to close this issue before moving on.

When you add an issue template and pull request template to your repository, project contributors will automatically see the template's contents in the issue or pull request body. Templates customize and standardize the information you'd like included when contributors open issues. This information can guide contributors to include the information that allows enhancement or bug reports to be reviewed quickly and identify the information that a reviewer would need to succintly review a new pull request.

Even if you aren't expecting to Open Source your project, Issue and Pull Request templates provide a starting point for other project contributors to use when creating new issues and pull requests. This makes it easier for everyone working on the project to review a new feature or gauge the severity of a bug quickly.

⌨️ Activity: Adding Issue and Pull Request template files

Issue and Pull Request templates use the following naming conventions:

 - Issue templates are named: `ISSUE_TEMPLATE.md`
 - Pull Request templates are named: `PULL_REQUEST_TEMPLATE.md`

1. Access the Code tab of your project.

2. Click the Create new file button

3. Name your new file based on the template you are trying to create

4. Modify your template file to include the information you want to automatically populate when a user creates an issue or a pull request, for examples of what to include read this

5. After editing your file click the Commit new file to commit your CONTRIBUTING.md file directly to your master branch.

   This is committing your template file directly to master.

I won't respond to this issue, just close it when you are done!

A contributing guide provides important information to those who may be interested in helping you with your project. Without a contributing guide, they might not know what you need help with, how they can get started, or how you like to communicate.

Although a contributing guide is typically found in Open Source projects, it can be useful for private projects as well. The contributing guide provides a quick reference for project contributors to the expectations when make contributions to the project. Even a the most veteran contributor to your project might forget how you handle a specific action item if it doesn't get dealt with very often. Having processes documented in your contributing guide makes working on your project easier for everyone.

⌨️ Activity: Adding Contributing guidelines

1. Access the Code tab of your project
2. Click the Create new file button
3. Name your new file CONTRIBUTING.md
4. Modify your new file with contributing guidelines for your project, for ideas on what should be included in a contributing guidelines file, read this stellar documentation
5. After editing your file click the Commit new file to commit your CONTRIBUTING.md file directly to your master branch.

I won't respond to this issue, just close it when you are done!

I think the idea and functionality can be perfected here, but have you thought about the long term and maybe deploying a version of this as a web app or having a mating browser extension? These are different projects unto themselves, but I am just trying to think about how to make this more accessible to people in the long term.

Collaborators

Part of what makes working on GitHub so effective is how easy it is to collaborate. If you want to give others the permission to work in your repository, you can add them as collaborators.

Things to watch out for

Whether your repository is public or private, inviting someone as a collaborator will give them push access to your repository. That means that they'll be able to make changes to the code. Depending on whether or not you have protected branches enabled, they may even be able to change the history on the master branch! Before inviting collaborators, make sure they are people you trust with your code.

⌨️ Activity: Inviting Collaborators

1. Ask for the username of the person you're inviting as a collaborator. If they don't have a username yet, they can sign up for GitHub.
2. Click on the Settings tab for this repository.
3. In the left sidebar, click Collaborators & Teams.
4. Under "Collaborators", start typing the collaborator's username.
5. Select the collaborator's username from the drop-down menu.
6. Click Add collaborator.
7. The user will receive an email inviting them to the repository. Once they accept your invitation, they will have collaborator access to your repository.

I won't respond to this issue, just close it when you are done!

When I first wrote the code, I used the name progress-o-meter, but later I decided to shorten it to prog-o-meter. It would be nice if we changed it in the code.
This task requires NO programming skills, but you need to be able to use the github workflow (see the CONTRIBUTE file for guides, or ask for help in a comment on this issue). It could potentially be a nice way to look through and get familiarized with the code for this project, before committing to a larger task.
To change from "progress-o-meter", to "prog-o-meter", you can go through the code (if your editor have a find function, you can use that, to find all the places in the file, where it says "progress-o-meter", just like in word)
It would be awesome if we could change it both in code and comments (this just means EVERYWHERE in the prog-o-meter.py file)

Nice Work!

Congratulations, you did it! 🎉

Now, you have your code set up in a GitHub repository!

What's Next?

There are some issues already opened in this repository to help you craft this repository's important files, including these:

• Add Documentation
• Release Your Software

There's so much more you can do with GitHub, and you have a solid start. Now...what will you learn next?

In the new feature added by @garroadran, where the user can tweet at their completion, we do not currently have the twitter logo included, because we need to figure out which format to use, to make the program compatible across operating systems.
There has been a longer conversation about this in the Pull request #73 so it will be useful to reference this, to gain an idea of the issue.

Please check in before starting working at this issue, since @garroadran might be handling it

Step 1: Planning the move

You have a few options when moving your project to GitHub. This course will expose you to these options, help you choose a path, and then guide you down the path you have selected.

I know some people like to get straight to the point while others like more information. For those who like more information, be sure to check out the drop-downs like this one ⬇️

Where is your project today?

To give you the best information, I need to know a little about your project. In the next activity, you will apply a label to this issue to help me provide the most applicable information to help you move a project to GitHub.

⌨️ Activity: Add a label to this Issue

For this exercise, use the following table to determine which label to apply to this issue.

1. On the right side of this issue, look for a section titled Labels
2. Click the ⚙️ gear icon
3. Select the label that describes your project
4. Click the ✖️ x at the top of the label panel when you are finished

For a printable version of the steps in this course, check out the Quick Reference Guide.

Watch below for my response

After you have added the label, I will add a new comment to this issue with next steps.

Sometimes I respond too fast for the page to update! If you perform an expected action and don't see a response from me, wait a few seconds and refresh the page for your next steps.

I think we will want to represent the user as an object so that we can store all of their information in a nice little abstraction. This will make it easier to store lists of users, update the user's data, etc.

I'm self-assigning this, but I might not actually get around to it for a day or two, so if anyone has strong feelings on how we should go about this, let me know.

Your project doesn't have a README.md file. Even though your project might be private, that doesn't mean the README.md file isn't useful. The README.md file can inform other contributors that you invite to your project how to work on the project, display badges from GitHub Integrations that display the health or status of the project, and more.

A README is often the first item a visitor will see when visiting your repository. README files typically include information on:

• What the project does
• Why the project is useful
• How users can get started with the project
• Where users can get help with your project
• Who maintains and contributes to the project

⌨️ Activity: Adding a README

1. Access the Code tab of your project.

2. Below the list of files in your project is a notification reading: "Add a README with an overview of your project.", click the Add a README button found within that notification

3. Edit the new README file to describe your projects, using the bullet points listed above ☝️

4. After editing the README file, scroll down and click the Commit new file button.

   This is committing your README file directly to master. Normally, you would create a pull request when making changes to your projects, but README files are very important on GitHub.

I won't respond to this issue, just close it when you are done!

Using releases

Why Releases?

Releases are GitHub's way of packaging and providing software to your users. You can think of it as a replacement to using downloads to provide software.

With Releases, you can provide links to binary files, as well as release notes describing your changes.

At their core, Releases are based on Git tags. Tags mark a specific point in the history of your project, so they're a great way to indicate a Release. Releases are ordered by a tag's date in the following way:

If it's an annotated tag, the tag object's date is used.
If it's a lightweight tag, then the commit object's date is used.

⌨️ Activity: Creating a release

1. On GitHub, navigate to the main page of the repository.

2. Under your repository name, click Releases.

3. Click Draft a new release.

4. Type a version number for your release. Versions are based on Git tags. We recommend naming tags that fit within semantic versioning.

5. Select a branch that contains the project you want to release. Usually, you'll want to release against your master branch, unless you're releasing beta software.

6. Type a title and description that describes your release.

   If you'd like to include binary files along with your release, such as compiled programs, drag and drop or select files manually in the binaries box.

   If the release is unstable, select This is a pre-release to notify users that it's not ready for production.

7. If you're ready to publicize your release, click Publish release. Otherwise, click Save draft to work on it later.

You can create releases from the GitHub user interface. Read this detailed documentation when you're ready to implement releases.

I won't respond to this issue, just close it when you are done!

Currently when the user reaches their goal, nothing happens (besides from the fact that the "1 more day!" button is disabled, to they can't add any more days)
This seems like a cause for celebration. Maybe we can display are celebratory message, gif, fireworks, or something else? Either as a pop-up window, or displayed directly on the canvas created in the ProgressGUI class.
Lets get creative :)

In the Tkinter window launched/opened by the StartGUI, the user have to either select "I already have a meter", or "I don't have a meter yet", and then click submit.

But if the user doesn't select either before they click submit, the program keeps executing, but lacks important information, and therefore looks very weird.
We need to make sure user clicks one of the radio-buttons before they click the submit button.

Suggestions:

• We can maybe have the submit button's state set to disabled, untill one of the radio-buttons are clicked. When one of the radio-buttons are clicked, it updates the self.choice variable, which is of the type IntVar. I think there is a method to tracking changes to IntVar variables, and maybe we can track the change, and when a change is made (i.e. a radio button is clicked), we can change the state of the "Submit" button to active (or we can get completely rid of the submit button, and just actively submit when we track a change to the IntVar self.choice)
• Another possibility is that we set one of the options to default, and takes that to be the user's choice, if they don't change it before they click the "Submit button". However, if we choose this route, we should probably make sure that issue number #26 is handled, so the user can go back, if they are trying to make a new prog-o-meter, and just accidentally input the "I already have a meter" option.

Hey, if you want, it would be nice to have people's name (first name or full name, whatever you prefer) at the contributor list at the bottom of the readme. I have added your github handles. If you want, you can add your names. @elheffe80 @garroadran @B-Souty

Let me know if I am missing it, but the user has to manually start the program and click the button to add days, correct?

If that is the case, then maybe it should be changed to log the time the challenge starts by using the datetime module or something similar and then if the user starts the program again the time that has elapsed will be automatically calculated