Questions about how to make my Github repositories work for me

I'm posting here because I don't know where else to post questions like this. Feel free to re-direct me.

I asked some questions here about setting up my Github repositories and got some good answers. However, since I'm needing help with my primary project, Question Bank Creator(QBC) here, I have more questions. Two major questions for this post:

Question 1: How do I set up my repository so that individuals wanting to help with the project will find it easy to see the goals and find a place to help?

Right now I think the repository is unorganized and messy. I've been doing some research along with watching some videos, and that may answer some of my questions. I suspect making use of the available tabs (after learning how to use them) will also help. However, I don't have the big picture in my brain. When a potential collaborator pulls up my repository, what does he/she need to find in order to get started? What does that look like?

Question 2: What is the proper etiquette to use when it comes to soliciting help?

Should I post a "Please come help me" topic here on this forum or would that be an abuse of the forum's purpose? In my mind it might be appropriate since QBC is written in Rust and I'm trying to attract Rust-literate collaborators. However, I don't want to become offensive while asking for help. Is there another place more appropriate for me to post an appeal for collaboration?

General guidelines for contributors should generally be placed in a file named CONTRIBUTING.md or similar in the repository root; GitHub has a docs page on this. You can also apply the "good first issue" label (or similar custom labels) to any issues of your repository that you feel outside contributors should focus on.

I'm not entirely sure what the best answer here is. I believe posting a request for help once (or very infrequently) on this forum would be acceptable, and the Rust subreddit might accept such posts as well.

2 Likes

Have open issues in the GitHub issue tracker. Issues can be anything from high-level goals to "this one specific thing needs fixing"; having a mix of both is useful. Write down everything you currently think you want to happen in the project. Make sure they are explained in adequate detail for someone who doesn't already have context. Use issue labels to organize them; GitHub has a default “good first issue” label which you can put on smaller issues that need less context to get started on.

If you have preferences about how contributions proceed, you put all that information in a CONTRIBUTING.md file. Think of it as a “FAQ” that you fill out with anything you realize isn’t obvious about how the project is maintained. However, this is not necessary if there is nothing in particular you want to communicate yet.

Have documentation of what the scope of the project is: information for them to figure out whether a proposed new feature for their own use would be accepted or rejected. This could be in the README.md or the CONTRIBUTING.md depend on how you want to approach describing the project.

Look at other repositories' issue trackers and documentation files to see how they organize theirs. If your code and project info is organized in familiar fashions, people will be on more familiar ground and more likely to contribute — and you might find ideas for things to write.

6 Likes

This is one of my favourite blog posts about how to make your project engaging to newcomers:

4 Likes

The first thing I personally look for is general information about a project in its top-level README.md file. Which is exactly what you already have, so that box is checked. (At least technically: See below for some suggestions to make improvements.)

The next thing I look for is developer documentation, typically by looking up the package(s) on docs.rs. Your package is not published, so a docs build will not be available, either.

Well, I'll have to start digging into the source and build the docs myself. I will want to quickly peek at the dependency tree by examining Cargo.toml, and I see three git dependencies that you have also not published (so, they also do not have a docs build).

Running cargo doc:

error: no matching package named `lib_jt` found
location searched: Git repository https://github.com/jtreagan/lib_file.git#620efb18

Oof! I can't build the docs because the dependency tree is incomplete... So, I check the Cargo.toml in GitHub - jtreagan/lib_file: A library of utility functions for working with files. and I see that lib_jt does not exist in the most recent version. Back in the Question-Bank-Creator repo, I can fix the build with cargo update. Now cargo doc builds the documentation correctly.

I do not see any documentation comments in the built docs. The only thing I can learn about the code is from the names of types and function signatures. This is "hard mode" documentation, and I would normally end my engagement here and move on to another project.

Building/running QBC works fine enough (on Windows, at least). There are a number of warnings emitted, which is concerning. But the application itself is running.

When it starts, I see two windows, one with a bright blue background and one that is bright red. Red is usually reserved for errors, and the maximum brightness on the colors strains my eyes. I am also confused by the red window, which is not modal, but floats on its own and can be moved to the background or closed. Do I need it? I have no idea.

I can click around in the menus, and if I decide to close the new windows without answering questions, there are error messages printed to the terminal. And an open-file dialog keeps coming up. It is unclear what it expects me to open. A lot of this is exploratory, rather than reading (or following) the instructions.

This has led me to a few simple suggestions:

  • Using a Cargo workspace will keep all of your dependencies in sync. Maintaining multiple repositories is always very difficult.

  • Writing developer documentation is seen by many to be not a fun task. But I really enjoy it! It helps me clearly think about the code. If I can't explain my code to another person, then I have probably written bad code. It gives me a good opportunity to fix design mistakes.

    • Writing good documentation is really difficult, even if I generally enjoy writing docs. There is a certain mindset needed to mentally put yourself in someone else's position. Writing for a new perspective is (I think) what makes really outstanding documentation. Because it helps you put necessary contextual information front-and-center for people who may be unfamiliar with your particular background.
  • Publish your crates (after the documentation is made presentable) so that docs can be readily accessed without requiring clone/build steps.

  • "Getting started" as a collaborator is much easier when there is a plan to follow. Add some issues in GitHub! Add labels like "good first issue" and "help wanted". Then organize these issues into projects that form a roadmap. Even if you can't attract collaborators, at least anyone with interest can see what you plan to do with it. That is often much more information than they can get just by looking at the current state of things.

    • Enable discussions and encourage community involvement!

    • Having every related package under a single workspace really helps here! You really want a single source of truth for all of the feature tracking workflow stuff, not have it spread across multiple repositories. (Unless it really makes sense to have them separate.)

    • Depending on the project, it may have very low engagement or none at all. Prepare for that as well. Don't do too much work on the social parts of project management if you are not in need of them.

  • Clean up the warnings. The first sign of a healthy code base is that nothing needs my attention when it has been built. The second sign is that it is lint-free: run cargo clippy --fix to automatically apply a number of suggestions it has out of the box.

  • Be judicious about application usability. The brightly colored backgrounds can be subdued to instantly make using the app more approachable. Address all of the runtime errors that come up when randomly clicking around in the GUI. Dial in the workflow so that you don't need two disconnected windows that are instantly confusing. Don't open a new window for every user interaction. It's very jarring and takes the user out of their flow state.

I wouldn't do all of these things for all projects. There is a balance to strike between building a community and just having a hobby.

Consider creating announcement threads on a variety of social platforms. I don't personally do this often, and I don't have accounts on many of those platforms. But I will sometimes make an announcement on the This Week in Rust newsletter. (They have a "Calls for Participation" section in each newsletter, like this one. This might be something worth trying when you are building your community. Here is a direct link to the CFP guidelines.)

Finally, I would caution that your project is still clearly in the very early stages, and it will be much more difficult to attract attention until you have paid attention to detail, yourself. More important than even documentation is presentation. Put a few screenshots into the README, add a project logo. If it does something really unique or intriguing, create a video/screencast. Write a blog post about what you are doing and why it matters. If you want people to be excited about what you are offering, be charismatic and show your work or at least make a gambit and promise what is coming soon.

7 Likes

In addition to what was said, besides announcing it in programming circles, you can try posting in dedicated teaching and homeschooling communities (on reddit or specialized forums). You might get an early wave of adopters that might file issues, suggest features, and—if some can code—may even send their first Rust PRs, it might be their first foray into the language :slight_smile:

You can lead with the fact that it’s free and open-source.

P.S. You can also post a (youtube) video on how to install and use your application. You can also bundle some premade exam questions which teachers can check out in the app, without needing to create questions themselves.

3 Likes

Hey, everyone. Sorry about taking so long to respond. We are in the midst of a move (from an apartment to a house) so my time and effort has been focused on that task.

Thank you for your responses to my questions. This is just what I need. You were all thoughtful and thorough. I have enough now to take some baby steps toward building the repository in a way that potential contributors will find useful. The learning curve for me here is still steep, but you all have given me a good start. I'm sure there will be plenty of minutiae on which I will need further input, so I'll come back here for that.

Someone above mentioned the difference between a solid project and a hobby. Learning Rust has been a hobby for me, I suppose, but this project is highly worthy and has the potential to be useful to many parents and teachers who are working to educate our young people. My first motivation for beginning to write QBC was/is that I personally need it as a tool to use writing some math curriculum, but it is bigger than that. Fleshing those motivations out more (maybe in an extended Readme.md) should, perhaps, be my first step on the road to building the repository.

Again thank you.

1 Like

Here is a point of confusion for me. When I look at crates.io I see it as a place for me to go to find libraries of functions and methods that I can include and use in my own projects (as long as licensing allows me to do so). That way I don't have to reinvent the wheel since someone else has already done that work and is offering to let me benefit from their work. So, if I document and develop my lib_file crate and publish it on crates.io, I will be helping other coders by letting them use my work. That's a good thing. However, you seem to be suggesting that I should publish QBC on crates.io even though QBC isn't a library that someone else would include as part of some other project. Publishing it on crates.io seems, to me, to be inappropriate and unnecessary. So, there's clearly something I'm not understanding or am misconceiving. Could you address that?

You can publish binary crates on crates.io, too. That allows people to easily install the binary on their system using the cargo install command.

1 Like

Publishing your work is not a necessity, it is a convenience. It’s a way for publishers to share code and for consumers to easily make use of it.

GitHub serves a similar purpose for publishers and consumers. What the crates.io registry adds is integration with cargo and docs.rs. You saw the cargo install command above for binary/executable crates. docs.rs is a host (and automated build tool - all you have to do in most cases is just publish) for developer documentation, mostly for public APIs. There is a way to build the API docs showing private items, which can be helpful (or too much).

2 Likes

I've been putting some of your advice to work. Dug into Rustdoc and read up (a little) on using workspaces. The biggest question was what to do with my three libraries. QBC isn't my only project that uses these crates, so it doesn't seem like including them in the (still to be created) QBC workspace was really workable. So current plan is to fix the documentation on each crate and publish it in crates.io. I've been focusing on the lib_file crate and have it almost ready to publish. I think. I'm going to start working on the publish part next and would invite you all to check the crate out and pass on any thoughts you might have.

My next step will be to do the same with lib_utils and lib_myfltk. After that I can return to QBC and apply your words of wisdom there. If you look at the QBC repository and click on its Issues tab, you will find an issue titled Add an Equation Editor. This part of the project (not yet started) promises to be extensive so the current plan is to include it as a separate crate in the QBC workspace.

Your thoughts will be appreciated.

BTW, if any of you have some ideas for getting started on that Equation Editor issue, I'd love to hear what you have to say. :>)

And question number 3 - how do you know that people actually hep, instead of making the project worse? It isn't a joke, I stopped soliciting help after found that tons of pull requests are actually crap, and now it's ChatGPT seasoned.

It won't hurt if you do. Workspaces are only for your development purposes, and make no difference after publication. A prominent example of a published library like this is that yoke lives in the icu4x repository.

I’m not recommending putting a package in “the wrong” workspace on purpose, but you can freely organize packages into workspaces according to whatever principle makes sense for development, without worrying about the implications for users of the published package. This can be useful for spinning off a library out of a larger project — you can develop it in the same workspace until it makes more sense to move to another workspace and (probably) another repository.

I'm wondering if some of the rest of you could weigh in on this issue. It's unfortunate that our friend @MOCKBA had a bad experience soliciting help from the Github community. Since that's exactly what I'm intending to do, I'd appreciate some more input. I'd rather not have it turn into a similar bad experience.

In my experience, actually bad PRs are rare. My own projects are often too oddball to attract much interest so I haven't dealt with very many PRs to them, good or bad, but the more popular open-source projects I watch don't seem to get all that much garbage either. I would guess the difference is that “soliciting help”, as opposed to merely having a public repository that accepts PRs, is plausibly likely to attract lower-quality attempts — probably also greatly depending on where you solicit help.

But it's certainly important to be prepared for the possibility of getting bad PRs. If you are accepting PRs at all (this is not required), you need to review the code.

If you’re in the position of “I built this part of the application based on $SOME_LIBRARY’s examples”, and someone submits a PR that changes the code that was copied from the examples, then you might not know whether the change is actually an improvement — in which case, you’ll have to read the library's documentation until you understand what the difference is. But, if that isn’t feasible, you can always reject the PR with “I am not sure this is an improvement and I don’t have time to review it in more depth”. Nobody has a claim upon your time just because you published some code — but if you want contributions, then you have to spend some effort on understanding and sorting those contributions. In the end, nobody but you is actually able to decide whether it is correct to accept a PR, because you’re the maintainer; you’re the project leadership. There are no magic words to get only high-quality help.

2 Likes

When people create pull requests or issues for your repo, you can just look at them as suggestions. You are free to close the issues or reject the pull requests. This takes some effort, but it is just life when you open your doors to input. Perhaps Mockba decided it wasn't worth it, but that doesn't mean you will decide that.

1 Like