I love a bullet list - I find it easier to read, but open to changes here.

I thought about including 'making feature request' in the bullet but I am not sure we want to encourage this. Note that the reference 'submitting_bug_feature' is to the section "Submitting a bug report or a feature request" which does talk about making a feature request.

I think it's ok to subsume "I found a bug" and "I'm missing a feature" under "issues" and to leave it underspecified here (especially since it is expanded in the link). This way, people are not specifically encouraged but the information on how to do it is still there.

This did not feel right here, with the introduction because it's quite technical. I could not find a good place to put it, with the current contributing guide. I've moved it to the section "Submitting a bug report or a feature request", which I think is okay for now.

It may be suitable in a (new) section about 'feature requests' (which we don't really have, though we do mention in 2 or 3 places about being selective about what we include in the project and why). It may also be useful to link to if we add a contributing code section (e.g., in the intro).

I've amended the wording here, ideally something big enough to require a SLEP should not get to the 'contributing' stage (without a SLEP).

What about this, will this strike a balance between setting expectations and still being open to everybody?

I am happy to add this.

I forgot to mention but I intentionally put code contributions at the bottom of the list because I think the other ways to contribute are probably more useful.

For new contributors, I think a better way to start would be to look at issues and confirm them, investigate the cause of issues (gets you familiar with the codebase), review other people's PRs (helps familiarise oneself with what is expected) - jumping straight to a code contribution is rushing ahead too quickly, and not building the base knowledge/background needed. (edit: I think with how complex this project is, jumping to code contribution is just not realistic for a someone learning, unless you have a mentor on hand. I can understand that the other types of contributions are less glamourous and historically less valued, but I think you need to work at building a foundation first.)

Maybe this suggestion should be added to the 'New contributor' section, and we could reference it here...

I am trying to think of a better way to phrase 'beginner'. Do you think 'new contributor' is not a good description? I don't love the term beginner (though I can't put my finger on why). I find when people are commenting, wanting to work on an issue, they often use the terms 'new to open source', 'learning'.

I have chosen "beginner" over "new contributor" since the latter come with different skill levels and there are very skilled people whom we'd very much like to contribute right away. Feel free to change "beginner" into something else though. I had also considered "new to open source" and like it.

I actually like the term new contributors, and I think the main point the paragraph above brings across is that the other contribution options should be taken into account first, which I like very much (because it is also the way I'm currently approaching the project, and I wouldn't consider myself a "beginner" 😇 ). Encouraging this path more explicitly might actually make it easier for new contributors to find starting points and could lead to higher quality first code contributions (though this assumes that people actually read this carefully (or that AI agents advise their users on this), which is a strong premise 😬)

I think "new contributor" is good because it communicates what you are new at (contributing). With "beginner" we leave it to the imagination of the reader to determine what it refers to (coding? open-source contributions? cooking? reviewing?).

In addition, you can be an experienced programmer/software engineer but still new to contributing to open-source. In which case I think starting somewhere else to learn about contributing is a good idea.

I think it's ok to subsume "I found a bug" and "I'm missing a feature" under "issues" and to leave it underspecified here (especially since it is expanded in the link). This way, people are not specifically encouraged but the information on how to do it is still there.

Maybe we could even make the intentions you mention below behind suggesting these things first explicit:

I liked adding these to the bullet list here, but I ultimately thought it would be better to expand the 'New contributor' section, to more explicitly suggest building a foundation first and how to do this.

I've linked the new contributor section at the end of this 'ways to contribute' section.

I actually like the term new contributors, and I think the main point the paragraph above brings across is that the other contribution options should be taken into account first, which I like very much (because it is also the way I'm currently approaching the project, and I wouldn't consider myself a "beginner" 😇 ). Encouraging this path more explicitly might actually make it easier for new contributors to find starting points and could lead to higher quality first code contributions (though this assumes that people actually read this carefully (or that AI agents advise their users on this), which is a strong premise 😬)

You remove the button which was showing the number of stars of the repos and where clicking on it would go to https://github.com/scikit-learn/scikit-learn/stargazers. I think that's completely fine because it was not very useful. If we really want (in a further PR), we could add a button where you can star easily, looks like GitHub makes your life easier https://buttons.github.io/

Ah I didn't realise it went somewhere. This was mostly because I thought the image didn't fit the format of the new bullet points. The problem with stargazers is that the page does not allow you to easily star the project, you just see a list of other users who have starred it.

we could add a button where you can star easily

as in we can add a button which when clicked, stars the project? Or would it just take you to stargazers?

I don't know how to word this clearly, and this doesn't need to be in this PR, but maybe something like "it may not the best place to begin if you are new to open-source contribution in general"

In my mind there is a difference between:

• new to open-source contribution in general
• new contributor to scikit-learn, but who has already contributed to other open-source projects

I think this also captures what @StefanieSenger was trying to add, so I think it is worth addressing it in this PR. Maybe that could be a way of phrasing it:

"it may not the best place to begin if you are new to open-source contribution in general. In this case, you should follow the suggestions in..."

Because the new section for new contributors now makes it more explicit, and this one here still sets expectations, even for experienced open-source contributors, but doesn't discourage code contributions in general (at least how I read it).

I've amended to Annes wording.

Essentially if you're new to open source in general, please make non code contributions first. The only snag here is that, would you suggest those that are not new to open source contribution, but are new to scikit-learn also read the new contributor section...? Or should we expect them to work out what they need to read?

I think from the bullet points above this section they should find enough resources on where to start. And no one is stopping them from skimming the new contributors section if they are missing any information.

I think @lesteve mentioned some ideas on how to re-structure the page into separate explicit "paths" for different target groups, but I would leave this for a follow-up PR at this stage.

Having a re-read, I moved the 'to read' contributing sections that pertain to contributing code down here, as we don't talk about code contributions until here.