Freecodecamp: Update contributing guidelines for adding project lifeline.

[benschac]

I know I'm not a consistent contributor to the project, maybe I'm missing something. It took me a while (30 minutes) to find an issue that's not being worked on and is ready for development that hasn't been worked on.

I'm not sure how you can tell what's important, what needs to get worked on next, if it's ready to be worked on, if someone is actively working on it. For me to do that now I need to look into and spelunk around issues.

Yes, the labeling system helps, but there are a bunch of issues that have help wanted that are out of date.

I think there's a better way for attacking issues and building features for this product (ends rant).
Is anyone else having this issue?

[raisedadead]

Hah, look who is here (just kidding, intentional pun..!). Thanks for your feedback.

TL;DR

help wanted is ready to be worked on, and if has a pull request is being worked on.

L;WR
This project operates very asynchronously, we have a Contributors Chat room, that you can follow along for regular updates and chit-chat.

But on the formal side this issue tracker is your best bet. Any issue that's tagged help wanted is open to anyone for sending in a pull request unless it already has one.

We sometimes assign some issues to specific collaborators but, that's very specific. And usually may not have the help wanted tag.

So, even if you find ambiguous comments on the issue threads that something is being worked upon, unless its very recent (~7-10 days), you are free to send in a pull request.

That said send in the PR only when ready for a review.

Now coming to your point of what is important, what's not. As for that, we would not encourage such philosophy, anything that has not been closed, is a bug or confirmed and is help wanted needs attention.

As for our long term goals, we have a few projects. You are welcome to have a look at those, but again, anything and everything is tracked as issues on the main tracker and is triage-ed, grouped.

Issues, that die in discussions and debates are closed with decayed, but maybe reopened if activity picks up.

Sure, some may issues may go stale but, we do our best to sort and attack those.

So you have anything in mind, for a better approach? That said, I am closing this issue because we are keeping the tracker for bug reports and code base only. Feel free to continue on the chat room or the forum?

Happy fixing!

[benschac]

For sure, and thanks. Maybe something like this in the Contributors
README.md section would be helpful. I obviously understand that FCC needs
to keep in light in terms of process since there are so many people
actively working on the project. Maybe since I haven't really worked on it
I don't know what's going on. But, something along those lines would be
super helpful.

On Tue, Feb 21, 2017 at 9:20 AM, mrugesh mohapatra <[email protected]

wrote:

Hah, look who is here (just kidding, intentional pun..!). Thanks for your
feedback.

TL;DR

help wanted is ready to be worked on, and if has a pull request is being
worked on.

L;WR
This project operates very asynchronously, we have a Contributors Chat
room https://gitter.im/FreeCodeCamp/Contributors, that you can follow
along for regular updates and chit-chat.

But on the formal side this issue tracker is your best bet. Any issue
that's tagged help wanted is open to anyone for sending in a pull request
unless it already has one.

We sometimes assign some issues to specific collaborators but, that's very
specific. And usually may not have the help wanted tag.

So, even if you find ambiguous comments on the issue threads that
something is being worked upon, unless its very recent (~7-10 days), you
are free to send in a pull request.

That said send in the PR only when ready for a review.

Now coming to your point of what is important, what's not. As for that, we
would not encourage such philosophy, anything that has not been closed, is
a bug or confirmed and is help wanted needs attention.

As for our long term goals, we have a few projects. You are welcome to
have a look at those, but again, anything and everything is tracked as
issues on the main tracker and is triage-ed, grouped.

Issues, that die in discussions and debates are closed with decayed, but
maybe reopened if activity picks up.

Sure, some may issues may go stale but, we do our best to sort and attack
those.

So you have anything in mind, for a better approach? That said, I am
closing this issue because we are keeping the tracker for bug reports and
code base only. Feel free to continue on the chat room or the forum?

Happy fixing!

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/freeCodeCamp/freeCodeCamp/issues/13494#issuecomment-281355649,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ACYxIxIshIm9VRiUWQIjiG4r31dq_qOmks5revKbgaJpZM4MHV5P
.

[raisedadead]

@benschac You are absolutely right. I'll update this issue so that the contributing guide can be updated.

[JosephLivengood]

Perhaps adding in progress or changing help wanted to in progress when someone takes the issue would help and requiring a solid estimated time frame when a user takes the issue so Mods know when its safe to throw a help wanted back on! I've seen this work great on some other repos

[Greenheart]

@benschac Thanks for bringing this discussion to life. I realized that I've thought about something similar the last weeks but I couldn't find words for it until I read this.

@JosephLivengood That's some great ideas! I think we should add a few sentences with steps that contributors can refer to regarding how to handle stale issues, assigning of issues and labeling.

[raisedadead]

@JosephLivengood @Greenheart Thanks for the feedback, I have seen in the past whole year that the flow I mentioned above https://github.com/freeCodeCamp/freeCodeCamp/issues/13494#issuecomment-281355649 seems to keep things async and reduces the clutter from a maintainers perspective, and keeps things async considering, a major chunk of the development focuses on curriculum.

We should maybe add more clarity in the guidelines on that. But again that's just my thought. Feel free to modify.

Workflow:

• Look for issues that are help wanted, confirmed or bug and are not assigned to collaborators, they are open for contributions, and do not need prior permissions. Feel free to open Pull request to those.
• If you found a bug, or an issue, that is not in the tracker you can open a pull request directly if you have a fix ready. Else just log a new issue, just make a comment that you are interested in working on it. We will confirm that and add a in progress label to it.
• Occasionally stale issues will be closed decayed and we would re-open if activity on those pick up.
• Feel free to check out the projects, for our long term goals, which group together issues from the main tracker, but in every case the above rules apply for triaging.
• Join the Contributors chat room to meet other contributors and get assistance or clarifications.

[Greenheart]

@raisedadead Nice write-up! I edited the last bullet a bit :blush: