Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I'm new to github and I like to help other people with their projects that I find interesting.
I know there are a lot of guides in the github place, but I think it could be nice to gather a bunch of real people's experiences.
So, I invite you to post about your first experiences in github.
Whether you are a not-so-newbie or you are a heavy rock in github comunnity, I think your lines could encourage real newbies like me about entering this great open source community.
It's pretty simple. You can summarise a simple community project's development into a circular process of just two simple actions:
Bug tracking. Testing the software, logging bugs, making sure they're filed in the right place, asking for more detail, etc. If valid, these reports carry the detail for the next phase:
Patching. Target a bug, reproduce it, change your code to fix it, test locally and push your patch. This loops back around to the first phase where the bug report is marked fixed or otherwise.
You've got to start with phase one. You don't have to follow a bug right through and you can help as simply as just hopping in and making sure other bug reporters are doing the right things (making sure there are dumps where applicable, making sure the tags are right, merging duplicates).
Or you can be more involved and test the software to find new bugs. The onus on getting things right is now your own.
Once you're more familiar with the project, its code and its maintainers, then you might be ready to get involved with fixing some of the outstanding bugs.
An important thing to remember is you can ask for help. Nobody expects an outsider to understand all the code or be able to fix all the bugs. Maintainers will very often be more than happy to help somebody get started because they'll often get their time back from work you do on the project.
EDIT: CodeTriage.com can help for this.
This is kind of an old question, but there is a new site that's trying to help people like the OP to find projects to contribute to.
The site is called Looking For Pull Requests (it's dead now in 2016) and it aims to help people looking for help to find people wanting to help.
You can just browse the list of projects and see how active they are, or you can even publish your project pretty easily.
Github is just a website which aggregates projects. You need to ask the project maintainers themselves how they want you to help. It is pointless asking here as we do not know the specific rules for the project you are interested in. Different projects have different ways of doing things and require help in different areas.
Learn how to use Git would be the number one thing to say. Oh, and make sure you following the coding standards.
Related
I saw people add many graphs, analytics, badges and many more things in their github profile. But how do they do this? See the attached picture and tell me about the process please.someone's github profile
you seem to be new here to Stackoverflow. Stackoverflow is a site where programmers help one another solve problems or issues that they are having with their code, environment, etc. Generally a question such as this would be closed, well at least from my experience. When asking a question you should probably ask something related to code or an issue (never ask how to do something with no existing code because people don't like that, coming from experience). Really only ask a question if there's an issue and a solution.
Back to your question, you can get all that stuff in that screenshot under stats here and you can add the tech stack stuff with any old github readme badge like this one. Just add what they tell you to your profiles markdown file, if you don't know how to do that look here.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
Just curious as to what the general consensus is for committing code of GitHub.
Should you commit only build-able code? Or is there a time when unbuildable code commits have their place?
Or am I totally miss-understanding GitHub completely? If so, please inform me how it should be?
If the master needs to stay buildable, I recommend that you make a branch, and merge the branch only when the code is working as intended.
GitHub is a place for sharing your code to everyone, it's your wish if you want to make it public for everyone to use or contribute or keep it private.
There are so many advantages in uploading code to GitHub :
1> Others can look at your code for reference and can also contribute to it
2> It keeps all your coding records with history so you can show them to your company when you apply for a job
yes, you can also upload unbuildable code and open an issue and wait for anyone else to fix it.
and it's a good practice to keep 2 branches one for buildable code (master branch)
and another test branch for testing stuff
In general for git, the master branch is reserved for only buildable features. Other branches can be reserved for in-progress features to be later merged into the master branch once completed and tested. GitHub, for the most part, follows these rules too.
To me, it really depends on the kind of project you are working on:
If the commit is for a private project, (and therefore probably has little following) you can do what you want
If the commit is for a highly visited project, maybe think twice before submitting unbuildable code without making a note in the commit message that it is unbuildable
As always, if you own the repo, you can follow any rules you like, but if it is owned by another individual, be sure to follow the rules that they set out for the repo.
It just depends. Some argue that all commits should compile or be "build-able", but IMO that defeats the purpose of frequent commits.
Typically, when I'm developing a project my rule of thumb is commit after 20 minutes or so of developing, and push every hour or when I finish the branch/feature I was working on. So if you are working on a project individually, then committing with issues in your code may not raise any problems. Committing frequently is the whole purpose of version control applications like Git, and you have the ability to go back to any previous versions whenever you like. If you are working on a project with a team there may be some guidelines as to when you commit/push, so make sure to check with your team if that is the case. Check out What are the differences between "git commit" and "git push"? if you are trying to better understand Github.
A year ago I have started an issue on github repository of a popular open source project. There wasn't enough data to fix it because bug was caused only by one closed source program. Recently I have stumbled upon other program that causes the bug and this one is open source. This should make it possible to fix the issue.
I have added new comment in issue providing new information, but it got no response for 10 days.
https://github.com/linuxmint/Cinnamon/issues/6253
I wonder if maintainers see comments on old issues in their notifications?
If they do did they discard it by accident or perhaps because in their experience most comments on old issues are useless?
Should I just edit last comment there slightly?
Will they see that?
Or what to do?
The good news is the project is not dead. Issues have been closed recently and PRs have been merged. Someone is watching the queue. The bad news is the project has over 800 open issues at this time which means they're probably swamped.
Open Source projects are typically run by volunteers, and that looks like a low priority issue. If you want it solved, do everything you can do reduce the work necessary to fix the problem. You've already given clear instructions on how to reproduce the problem, that's a very good start.
The single best thing you can do is submit a PR with a complete patch including tests. Be sure to conform to their developer guidelines. That project does not leave PRs open long. If you can't do a complete patch, take a stab at it and submit the PR asking for help. If you don't know where to start patching, make a comment on the issue asking for help with where to start.
Basically, do the work. If you can't do the work, show a willingness to do the work.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
GitHub is a great place to share accomplished projects for veterans. It is also a good place for beginners to show their baby steps learning a new language. I am learning Java by debugging someones' else final code in tutorials. For instance, bot's logic in tic-tac-toe (original code is posted in GitHub) or a calc that displays "6.0-" instead of "-6" or crashes after a sequence "0/0=" instead of showing "NaN" (original code is posted in a blog only). Some day I will contribute to comunity, but for now the goal is to make it easier for the employer to evaluate my skills.
I want to gather my work in one place and give a credit to actual authors of the program. I considered using
//Corrections to bot's logic. Handling forks. Stepan's code
But that doesn't feel right. How should I proceed when authors post their stub on GitHub or elsewhere?
Thanks in advance,
Stepan
You can submit a pull request and make your contribution to the project. Once you push it with a commit mentioning the changes you have made, the original repository owner can decide whether or not to merge the branch you have created.
From [docs],
Pull requests let you tell others about changes you've pushed to a
repository on GitHub. Once a pull request is sent, interested parties
can review the set of changes, discuss potential modifications, and
even push follow-up commits if necessary.
This discussion suggests that:
(1) If the original author didn't post his code on GitHub, than just post it on your page. Give a credit to the original author by saying where the program comes from and placing comments like
//Fixing [description of] problem (your nickname)
to indicate your contributions
(2) If the project comes from GitHub try to push changes first. If it didn't work in a reasonable time - fork it. You will have your own source code with smart bots and exception handling.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 3 years ago.
Improve this question
So looking at different version control systems: subversion, accurev, surround, tfs, bitkeeper/git/mercurial
Subversion: I see it's quite the popular standard
Accurev: There seems to be a love hate relationship around it.
Surround and TFS: I haven't seen many comments around them.
Bitkeeper/Git/Mercurial: Seem pretty popular, but I think "distributed" may scare my manager lol
For some reason he seems attracted to Surround and it's not because of sales pitch. We had originally downloaded it for evaluation played around with it but nothing came of it. So now we are back to looking at scm and wants to try it again. So far I haven't seen any buzz around it like some other version control systems. Same for TFS
I've been using Surround SCM at my job and I'll say it is what it is, but there are a few things that I find lacking. Though, I've heard that surround scm integrates well with surround's issue tracking system, but I can't comment on that because we don't use that.
I personally find the UI to be buggy and confusing.
The workflows are confusing and often offer you with prompts that don't apply, so you get used to ignoring warnings.
eg. "are you sure you don't want to auto-merge?" "Are you sure you want to overwrite files?"
The UI always badgers you to use the auto-merge feature but every
time I've tried it, it ends up messing up my code (C#).
On top of that, the packaged diff tool (Guiffy) is buggy and doesn't display text
properly.
Weird workflow quirks can result in your changes being overwritten.
It doesn't do directory syncing
...which means that every time you add a new file to your project you must by-hand go and add it to the SCM repository. If you don't, everything will look normal to you until one of your teammates emails you because you broke the build.
There's no good way to copy over revision histories when you are branching
... which means that you are less likely to branch when you should be. There's nothing more frustrating than to have to store code locally because you're making changes right before a release and your team refuses to branch the code into another repository.
There's no good way to blacklist certain files from being checked-in or from being overwritten during an update.
If there's a file that you don't want to check-in then you're left with the painful chore of scanning through a long list of files and deselecting those you don't want every time you want to check-in. Yuck.
Features aren't documented that well
Of course, they release a user's guide but it's about as helpful as Microsoft Windows help function. It tells you step by step how to do things in the UI (ie. "click 'Create Shadow Directory', then click 'OK'", but it doesn't tell you what those features are, how they are intended to be used, what actually happens server-side etc.
Btw, if you know of any good way to get around these problems let me know :)
Danger! Danger, Will Robinson!
Surround is a data jail. Once you commit to it, you're stuck. There is no known way to get your history back out to another SCM. Don't get trapped!
This tends to be a problem with closed-source SCMs in general, but I have direct reports that it's especially bad with Surround.
Subversion, git, Mercurial, or Bazaar would be better choices.
I have used Surround at my job for about three years.
It does work well with their (Seapine's) test management and issue tracker program. If you are already using TestTrack, I would say Surround is a good choice.
In general I agree with #eremzeit, but the 'buggy and confusing' comment rarely applies to our workflow. The default diff tool (Guiffy) is bad, but often good enough.
One part I like is the easy ability to share files across repositories without needing to share a whole project/repository. Git does not have a mechanism to do this easily.
Last note: we have used Surround on Linux and Windows and it appears to work just as well on either. It is nice to have the same interface.
Surround SCM.
Pros:
Can apply a development work flow for all files. No two revisions of a file can be in the same status in the work flow.
Has a good UI.
Good licensing system.
Cons:
Stores all data in a RDBMS.. heading for a performance problem if the repo size is huge.
Does not support atomic commits. (you can do atomic commits but the files are still revisions and cannot be refereed using the changelist #)
My ideas about other tools
Subversion suits well for a corporate setup. Perforce is like subversion but faster and has a good UI, simple licensing terms and really super support system.
Recently Accurev has gained a strong footing with its innovative branching methodology.
IMHO. go for tool sets that interact well with your defect tracking, test case management and build management solution. This would help you create a good developer ecosystem thereby saving time.