Unable to add more than 1200 items to the project

[zaporylie]

Projects cannot have more than 1200 items. To add more, please archive or delete existing items.

Do we need such a limit? Kinda strange to see that projects are actually limited in terms of the number of items.

I wasn't able to find a single place where this limitation is documented, including official docs 🤕

[joneff]

I am assuming because there is no bulk add, very few people have actually added a lot of issue and reached this limit.

[zaporylie]

At least there's a way or archiving items in bulk: shift+space followed by shift+down and finished by single 'e'; archived items don't count against the limit.

But why the limit is 1200? why not 1000 or 1500? 🤷🏻

[nkolev92]

It's relatively easy to write automation that bulk adds issues to a project.
We hit this limit pretty quickly :(

[allenjzhang]

There was still no easy way to add issues to a project from another public org (with maintainer status).

[guillaumefont]

We use a project to manage our roadmap and we just hit the 1200 limit today. It's a big deal for us as it would prevent us from migrating our whole roadmap in a project...

[csumpter]

We hit this limit and I'm looking for the ability to automatically archive items but I don't think it is exposed via API yet?

related: #5799

[csumpter]

bump on this issue. trying to archive too many cards at once causes the UI network call to throw a 502, so without being able to easily manage the archiving of cards, you are forced to manually break up archiving cards into chunks so the Github API can handle the request without error.

[Marychoffel22]

Duplicate

[tay1orjones]

Auto-archive support is now available: https://github.com/orgs/community/discussions/36466

[Marychoffel22]

Duplicate

[zaporylie]

How come?

[Voxelot]

This is a pretty big limitation since we're using a single org-wide github project to manage issues across 10's of repos. We could partition the project, but even with splitting into many projects it won't take us long to max those out. Can we get the limit increased or removed entirely?

[nkolev92]

even with splitting into many projects it won't take us long to max those out

Same situation here. In fact, splitting is them affects our workflows, so I wouldn't even consider that an adequate option in most cases.

[Voxelot]

Has anyone had a good experience with zenhub? Looks like it's free for open source projects and basically already does everything github projects aspires to.

[misskniss]

I am trialing Zenhub right now. It has its pros and cons.

A few examples:

1. It handles Epics but it can be a little funky if you have vanilla Github users that do not use Zenhub because Zenhub Epics are just issues labeled as Epic to vanilla Github. So Github users lose the view of what the issues are in the epic unless you are using the task lists in the issue description. While I love the task list handling in Github, you then have the problem of needing to update that task list for every add/remove from the epic in Zenhub unless you automate it somehow - so that is fun.
2. For whatever reason, Zenhub is dropping support for milestones (it reminds me constantly in my current views of its UI). So you have Github milestones not supported by Zenhub (except for some reporting) and Zenhub releases not supported by Github - so that is also fun. Zenhub mentioned recently that I am using an 'old view' but I am right in the middle of a major deliverable and switching to a new view at the height of an impending deadline is not my jam - but bear that in mind.
3. Zenhub will give you the pointing and reporting that you want if you are looking for things like velocity, control charts, burn downs, cumulative flow, etc. The Release chart will also do an estimation of points for yet-to-be-pointed items in the list based on the per-issue average points at that time which is handy.
4. Zenhub will not (without intervention) detect if something is in progress - even when it seems it should, out of the box, know this is if there is an attached PR. I prefer pm tooling that will catch a branch created with the issue number and auto move the issues to the correct pipeline.
   Zenhub has been responsive to reporting these sort of issues though and I have not dug into any automation beyond the out-of-the-box Zenhub.

While I can see what the Github peeps are going for with Projects and the reason for the limit, we blew past that limit a long time ago with our issues (we also did not originally know about the limit). Granted, at the time, I was testing it out as a full Project Management tool option - it sounds like it is simply not meant for that (yet?) and that became quickly obvious.

For instance, if want epics but only have issue task lists (that cannot collect points) acting as 'Epics' and/or Projects that seem like 'big Milestones with better views" - things get a bit hairy depending on the volume and zoom level you need for the work. If I could get all the other items I need form a project management reporting and organizing perspective, I would switch to using Github's in a heartbeat.

[csumpter]

Github - could we get a signal if your team plans to action this problem in the near future?

[azenMatt]

👍

For the archive, we are working on a couple of things to make this better, first up (and very soon) is the ability to view the archive of items with the project. Making it easy to see what has been archived and restore the item if needed.

On a longer term time horizon we will explore altering the number of issues that can be included in a project, but this isn't something we are planning on changing during the beta at this point.

[zaporylie]

I am currently hitting the ceiling of 1200 active issues within a single project. I've been manually archiving closed issues continuesly (given there's no automation to help with that) but now it's really either not creating more issues or moving to another solution which is really a Sophie's Choice. The documentation doesn't mention the limit either which is a bummer.

[nkolev92]

One of the most common project uses is likely to be a means to represent the full product backlog.

Unfortunately there's no means to do that with the projects beta due to the issue count limitation.
Our repo for example has ~1800 issue, https://github.com/nuget/home/issues.

Curious if the restriction is something that's more of a technical or more of a product decision?

[vojtech-dobes]

Honest experience: learning about the limit is the only thing so far making me question whether attempt to embrace new GitHub Issues/Projects is a good idea. It's so far amazing experience, but only if this can serve us for foreseeable future (we have some 13000 issues, 1500 of those currently open, and that's just our main repository). Hitting the limit and then having to juggle older ones to archive them (and have really inconsistent historical views afterwards) is a thing I dread when we hit it.

10x times bigger limit would alleviate my worries during Beta, of course I hope the limit is only product decision and not a deeper technological constraint.

I also imagine you would have to deal with this anyway if there should be some support for "all issues automatically in Project" feature.

[aw185176]

@csumpter @zaporylie - are you looking to have more that 1200 open issues? or would archiving closed issues help here?

Is there an API for archiving V2 project items? I only see APIs for deleting V2 project items.

[dethfire]

Yes please increase this very trivally small limit

[pawelru]

This limitation does not make much sense together with the Insights feature. I want to analyse historical trends (e.g. amount of work spend on documentation) but I can't because I need to archive old items which means that I will loose some data.
Beta Issues is there for a while and as the time goes by there would be more and more people reaching this limitation. This should be prioritised.

[mariorod]

Hi all ... we envision projects to be created to plan and track work in a variety of scenarios:

• a feature to completion
• a release tracker of what is shipping in the company
• a roadmap (like we do with ours)
• planning and tracking the work a Team is doing
• planning and tracking work across a product line (instead of pivoting by team you pivot by org or product - usually in smaller companies)

For the most part in all of those scenarios we want to encourage active work to be planned/tracked and not an endless sea of backlog items. We have seen team after team after team struggle with this, so we want to set lanes to help them avoid that pain.

As teams complete work we are also giving them the ability to archive. Archive gets those completed or no longer interesting items out of the way but you do not lose any of the metadata. In the future, Reporting will also work across this set so the idea is that you do not have to worry about this limit to then capture learning and history.

The 1200 is also to prevent users using projects like a repository. A repository already allows you to put millions of issues in there, so we really do not need another container to just store a large number of issues. But now, as many have commented ... the problem is that projects are the only way to work across repositories ... so if a team really wants to understand and prioritize their work across them this is the ONLY way.

We agree and hear your feedback ... so we are committing to solving two scenarios, which will eventually not have you worry about the 1200 limit (since that is mainly a soft limit and not a technical limitation of our store).

1. We will ship a set of features that allow you to query and manipulate data across repos that do not have a limit
2. We will ship a set of features that also unshackle creating an issue from a repository ... you see the start of this with DRAFT issues and how powerful they have gotten.

In all, I want to thank you for the feedback. We hear you. The 1200 limit is mainly a soft limit to make sure projects are used appropriately and match the value they will provide in the present and future. We will work hard to make sure we either expand projects or provide the necessary capabilities to allow you to succeed at scale.

Thanks.

[aw185176]

The 1200 is also to prevent users using projects like a repository. A repository already allows you to put millions of issues in there, so we really do not need another container to just store a large number of issues. But now, as many have commented ... the problem is that projects are the only way to work across repositories ... so if a team really wants to understand and prioritize their work across them this is the ONLY way.

Given that repositories have none of the features that projects have, it is unclear how you would prioritize work within a single repository's issues page.

[ftrotter]

The 1200 limit is mainly a soft limit to make sure projects are used appropriately and match the value they will provide in the present and future.

With respect, this seems to be profoundly false, and the fact that you believe is a reasonable sentence is an indication that Github is not able to think about this as a reliable enterprise solution. There are two massive misconceptions here.

A "soft limit" means that the number can be raised by us, the end users. If we cannot change this, then it is just about as much a "hard limit" as you can get. In our world a hard limit is "Something that github has done to put a line in the sand" that cannot be worked around. Like the size of a file in a github repo. It makes sense that you would decide the file size limit, because there are huge implications to trying to support "limitless" file sizes. This is not the same as that. This is your design team putting a brick wall in place that any sufficiently large project will eventually hit.. and then when projects do hit it.. Github says "you are not using projects right". The notion that you think it is a "soft" limit because you can change it is a big problem. The fact that you are so confused about this to represent to your customers that cannot change this setting that it is a "soft" limit is a gargantuan problem.

I am happy to retract this statement if I missed the place in project settings where you can set this to 5000 or whatever.. but otherwise this is the precise opposite of a "soft" limit in every way.

What is even more problematic is the second problem, which is your phrase "used appropriately".

There are 1000 different ways to use a git repo, and 10000 different ways to use github on top of that.
The idea that you are setting a limit like this.. which is inevitably a surprise to everyone who experiences it.. and that you have decided to do that because you understand how we should appropriately use projects is profoundly insulting. The fact that people on this thread are saying to you "but wait, we want to use it this way.. why cant we do that" should not be happening

We are now reevaluating our decision to use github projects at all. We will find a temporary workaround in this case. But the idea that your UX team is presumes to create a wall like this, without any kind of setting to get around it apparently, means that you will continue to think this way.. derailing our organic use of the projects system whenever your understanding of how it should be used differs from ours. It is a signal to us that our use of the projects features could be derailed at any time, because of arbitrary decisions made by your team.. and we just cannot have that. It would be one thing if there had been a warning when adding issues 1100 to 1200 that said.. "whoaa there.. you are about to reach your limit on issues.. " but that is not what the system did. Instead a user had an expectation that they would be able to create new issues.. and they were simply told "no more sorry". Which is going to cause a minor company seizure as we profoundly reevaluate how we approach everything.. because we had assumed for months "hey it looks like github projects works as advertised".

This is a pretty massive missed expectation, and the damage to trust in Github (and those that championed Github.. i.e. me) is not going to be trivial to get over.

I recommend everyone else reading this to also re-evaluate the use of this system. Because this is not just a bug, this is a team-level dysfunction that will arise again in different ways in the future.

Perhaps I should temper my opinion on this given that this is a beta feature.. but I cannot see how that makes a difference. A beta status means "hey this system has warts, and you can tell us and we will fix it" but this is dozens of testers saying "this is a wart" and the team is saying "not it isn't, your using it wrong". This means that the basic feedback loop that is implied by "beta" is not actually working.

-FT

[spoonernz]

Seconding this - this is the core driver we are re-evaluating our use of github projects and looking to pursue other tools.

[mtcA6]

What works for a small private sector team isn't going to necessarily work for a massive government project working in the open with 100+ teams creating thousands of tickets a month.

The strength of your belief that 1200 issues will ensure that projects are used the "right" way belies an naïveté in your customer's processes and the size of their operations.

[bisdevres]

@mtcA6
they are working on increasing the limit.
see github/roadmap#776

[guylouis]

We're an organisation working across several large repos, and want to use the project feature to manage cross-repos epics. We tag issues with labels to create these epics. The insight feature is particularly attractive for us since it allows to create cross-repo burnup charts for each epic ....but we're totally blocked by the limit of 1200 issues per project ...

[emkaminsk]

We hit the 1200 issues per project limit as well, is there a way around it? Given that we don't see ways for bulk migration, bulk archive this means we will have a lot of extra manual work.

[tay1orjones]

Auto-archive support is now available: https://github.com/orgs/community/discussions/36466

[tay1orjones]

Auto-archive support is now available: #36466

[zaporylie]

I wish I could say it solves the issue but it does not. The issue in question is that GitHub Project has a hard limit of 1200 regular items and, what I just learned about, 10000 archived items.

Note: A project can contain a maximum of 1,200 items and 10,000 archived items. To learn more about automatically archiving items when they meet specific criteria, see "Archiving items automatically."

https://docs.github.com/en/issues/planning-and-tracking-with-projects/managing-items-in-your-project/adding-items-to-your-project

The project I am working on already has over 2500 archived items. I suspect soon enough I'll hit that limit too and - what then? I'd have to remove archived issues from the project? I don't like the sound of that 😅

[primeroz]

Hitting the same issue ( but i did reach the 10000 archived items limit ) and the auto archive feature disabled itself causing me to also hit the 1200 items limit in the project.

I guess the only option is to empty out the archive

[darpank]

@primeroz you can ask to be added to the Unlimited Archive beta in https://github.com/orgs/community/discussions/52805

[darpank]

@primeroz in the short term you may have to delete some from the archive. One other thing that worked for us is to move some issues into their own project. We had multiple teams in one project with different labels and views for the sake of convenience, but logically we did have issues that could sit in their own project. Of course, you may not have that scenario but thought I would brain dump everything we went through. Looks like a larger limit for unarchived issues is also coming in Feb.

[artumi-richard]

I can see how having a limit of 1200 items and 10,000 archived items would help with implementing GitHub Projects, but it seems to be the case that people want to have visibility across all their repos at the same time.

What might help is a separate workflow once people go over the 1200 items. Is there a way get a view across all issues in an account? Or at least, all open ones?

[Voxelot]

I think gitlab lets you view all issues from each repo in an org pretty easily already.

[whakkee]

https://github.com/issues?q=is%3Aopen+is%3Aissue+archived%3Afalse+user%3Aorgname

(Where orgname == the name of your organization)

[zaporylie]

☝🏻 gives me WSOD

[azenMatt]

A quick update here, we are in the progress of increasing this limit - the first step was to make the archive 'unlimited' which you can see more on here - https://github.com/orgs/community/discussions/52805

I'l keep you all posted as we keep progressing and let you know when there is a beta you can join to give us feedback 😄

[bisdevres]

@azenMatt great to hear.
i like to be informed when the beta is available.

[tnykodym]

@azenMatt , please do you have any target dates when the "unlimited" archive (and potentially the increased amount of project items) will be implemented on github.com and then also on the GitHub Enterprise?
Thank you very much

[azenMatt]

@tnykodym - we have an alpha of the unlimited archive live now - https://github.com/orgs/community/discussions/52805 - if you have a project that would benefit please feel free to comment in that issue with the URL and I can get it added. I don't have a timeframe for when the increased total items will be available but we should soon as we continue to build out the experience

[ss185994]

Would love to be notified when there's an increased limit.

[dhanushkar-wso2]

Does this project increases the project issue limit from 1200 to some higher value ?

[MrChocolateMoose]

Since this is a soft limit, please make this configurable or increase it greatly. It appears that PRs are counting against this limit so it fills up faster than you would think for any serious project. There are so many pain points that are self induced that make it hard for a serious enterprise organization to try to use Github Projects.

[donnavitan]

We hit the limit today and would appreciate the ability to add more.

We need the ability to manage our issues effectively, including PRs when our community members are contributing solutions.

Our team appreciates being able to work and manage our project in one tool, however, this limitation is not helpful. Especially when our organization is recommending/pushing us to use other well-known project management tools. Github is making it hard for us to effectively work with this arbitrary limit.

We'd appreciate any help in this regard. Thanks!

[chris-griffin]

@azenMatt would you be able to confirm that this is still on track to be in public beta by the end of the year per the roadmap item?

[agneszitte]

@ankneis please can we have an update, to have a better idea if it would done at least next month (or more in March...)

github/roadmap#776
Thanks in advance for the feedback!

[azenMatt]

We are on track to start the beta in Feb, @evi-liu will have more updates for you all on this soon.

[agneszitte]

Thanks a lot for the feedback @azenMatt! Really appreciated!

[chris-griffin]

@evi-liu my org would love to join the beta!

[tomjamon]

@evi-liu My org too would love to join the beta :) Any news ?

[evi-liu]

👋 Hi all, thank you for your patience and invaluable feedback on our GitHub Project item limit. I'm happy to share that the private beta for unlimited project items shipped today! 🎉

Please read the changelog for more details, including how to join the waitlist and what is currently supported versus still not yet supported.

If you are a project admin and you're not seeing the Join waitlist banner, please see this Community Discussion for more details on how you can opt in to the private beta.

[ankitnayan]

Is this available in all plans? I am still seeing a limit of 1200 items in my existing project. If it needs project migration, I am not finding the migrate option as per https://docs.github.com/en/issues/planning-and-tracking-with-projects/creating-projects/migrating-from-projects-classic

[ankitnayan]

I see these 3 options instead.

[darpank]

@ankitnayan please see https://github.com/orgs/community/discussions/139936 and follow instructions there to opt in to te public beta. HTH, DK.

[ankitnayan]

thanks