I would like to know if there is any official TODO list for Allegro 5 lying around here, and if not, or if so, I would like to make a wiki page for it.

SiegeLord told me of the issue tracker for allegro on github, which can be found here.

https://github.com/liballeg/allegro5/issues

I'll start a wiki page for it, and people can edit or not at their leisure if they have definite milestones for allegro to complete or maybe a timeline of releases.

https://github.com/liballeg/allegro_wiki/wiki/TODO-list-for-Allegro-5

I don't know of any TODO list specifically.

I thought of something that we could add to the TODO list. I thought we could use more demo's and examples and I was wondering how others felt about that.

Things like Phaser have a huge list of examples (http://phaser.io/examples) demonstrating all aspects of game development. Allegro could do more in this regard.

A5 has quite a few examples, but I agree, maybe another demo would be nice. There's also Allegro Vivace, which is a pretty comprehensive tutorial.

Feel free to add your suggestions to feature requests and suggestions on the TODO page, and if they're 'approved', they can be added to the TODO.

I just thought this might be a place to plan for long term goals of Allegro, or short term goals either.

We have documentation on the library. However, I feel it is lacking in substance. We could use a more detailed set of documentation on the library and the examples. Maybe even add example bits of code on some of it.

That's a little broad. Do you have any specific entries you would like updated?

In my experience, the full TODO list is always the issues list on GitHub.

I'd suggest creating an issue with a list of proposed mini-projects (like more demos) that you'd like to do, and bring people's attention to it. A wiki page is not really a place to do that. It's more for static documentation and tutorials, and doesn't have any notification features for changes or live discussion/contribution.

GitHub issues is pretty fantastic, to be honest. I'd recommend getting used to all the features, tagging, checkbox lists, etc.

If we wanted to do something specific, like create a more comprehensive set of demos, I suggest tracking that as a milestone.

It's very easy for issues on Github to get completely lost. Right now there are 300 open issues. Are you really going to read the entire issue list?

The TODO list on the wiki is for an overview of development. Perhaps milestones have their own place on Github, but a separate list of larger issues should be good for allegro.

Creating an issue for every example / demo that needs to be worked on is a waste of time and is a good way to get ignored.

Discussion belongs on the mailing list, not the wiki. Of course the wiki can be discussed on the mailing list, so there's really no need to include discussion on the wiki. The old wiki had discussions and they often went nowhere.

Creating an issue is a great way to do it. Communication and discussion is automatically opt-in and focused on a specific topic/goal. The company I worked at had about 1000 employees and it worked fantastically smooth.

If things are getting lost in the list, then there simply isn't enough interest in the project/issues, it's not important enough, or there isn't enough manpower or management to draw/assign people to the tasks.

The real advantage of GitHub issues is that everything works the same way. There's no cross-talk between mailing lists, wiki updates, issues, etc. Everything is localized and discussion is fluid.

Issues are not appropriate for larger tasks. They're designed to be simple to fix and easy to cross off.

A TODO list is for longer term goals. Issues don't belong on it, nor do TODO belong in issues. I have to disagree with you on this.

There are simply not enough developers to handle this many issues. They are backlogged, out of date, open beyond their lifetime, and are too scattered.

A TODO list brings larger groups of issues together, as DanielH suggested, working on examples and library documentation is something for a TODO list, not a 100 issues. A TODO list is simply beyond the scope of an issue tracker.

As you stated earlier, perhaps some of these could be made into milestones. I'm not familiar with how that works on Github, perhaps you could elaborate.

There was a wish list of things people would like to see implemented like clipboard access.

[EDIT]
Didn't realize it was 8 years ago. I looked up the post I posted about it. There was a wish list for drag/drop. So I implemented a custom event for dragging/dropping files into the display.

Here's an example of a GitHub Milestone for AllegroFlare version 0.9:
https://github.com/allegroflare/allegro_flare/milestone/1

Here's an example of a single GitHub issue that represents a larger project:
https://github.com/allegroflare/allegro_flare/issues/106

What you just described is an issue. The thing to do is create a new issue that outlines this problem, and then draw people's attention to it. This allows for there to be a centralized location where that particular problem can be discussed and owned. You might even propose a solution, something like StaleBot, or doing a quick blitz and spending 30 minutes a day to close discussions that are too open-ended or are no longer relevant.

That's basically what that 2nd link I have above is (this issue). There were too many issues in the AllegroFlare repo, a lot of them were out of date or could be closed with some quick work, so I created an issue and tracked the progress. Each issue had its own thread/timeline and "discussion".

But I think that's a little off target. If you're proposing a new set of things that should be done for Allegro, honestly, I'd still create an issue. Throw all the ideas that come up into there. You might try to make other existing lists obsolete (like the "wish list" DanielH mentioned) and consolidate them all into one place.

For example, here's an AllegroFlare issue where I list out some proposed new classes:
https://github.com/allegroflare/allegro_flare/issues/90

Allegro uses milestones for some mild organization of issues: https://github.com/liballeg/allegro5/milestones. I've also occasionally labeled issues: https://github.com/liballeg/allegro5/labels. That said, the additional organizational bureaucracy seems unnecessary unless there's commitment from someone to actually work towards those goals.

I added everything mentioned to the TODO. Some of them, like native clipboard support could have its own issue, and that's fine, we can link from the TODO to the issue.

I think the TODO serves a better purpose as a high level overview of what we would like to see implemented in Allegro. It's not quite the same as a milestone, but milestones could easily be included in the TODO.

That said I don't want to repeat everything on the TODO, but rather gather an overview of what needs to be done.

EDIT
@DanielH
Re: Drag and drop - I think it's a great idea, I use it in my own gui for widgets, but I don't have native file drag and drop. All that is is passing the name to the app. I think you were on the right track.