EPIC

EPIC: Enhanced Project Information and Control is a web-based project management system like Trac and Redmine.

Latest Updates

Issues

Feature request #28 (Convert "Instinctual" mockup into a theme.) revision 4: Much more in `pubhost` revision 307; now, we have mostly usable navigation, as well as in-page loading so we don't need to do full page loads with all chrome in order to change pages on a project.
Feature request #28 (Convert "Instinctual" mockup into a theme.) revision 3: More work in `pubhost` revision 306; now, instinctual can kinda be used as an actual theme, though it's missing a lot of navigation functionality.
Feature request #28 (Convert "Instinctual" mockup into a theme.) revision 2: Started implementing in `pubhost` revision 303.
Feature request #28 (Convert "Instinctual" mockup into a theme.) revision 1:
Feature request #22 (Make themes self-contained) revision 2: Fixed in `pubhost` revision 302.
Bug #3 (Issue form fields poorly ordered) revision 3: Started fixing in r258.
Feature request #27 (OpenID support) revision 1:
Task #26 (Evaluate maintaining 2 separate forks for in-house project management and publicly-hosted project management) revision 5: After discussing things with morgul, what we've come up with is basically that all branches derived from a project's branches would be discoverable under that project, but that the project maintainers would be able to choose what branches get listed as "official" branches, (along with optional descriptions for each branch) and choose which branches' issues show up under the main project issue list, etc. All non-"official" branches would simply be listed in an "other branches" section.
Task #26 (Evaluate maintaining 2 separate forks for in-house project management and publicly-hosted project management) revision 4: I'm pretty sure you're right, that none of the public hosting sites are meant to be user-deployable. Honestly, I like the loose association between branches on github/bitbucket, because it implies less of a rigid "project" structure. (and therefore less of a user hierarchy) I can agree that it can be frustrating to find the "main" branch for a given project, but it doesn't generally cause me an issue. (most people know that Qt is made by Nokia, so they'll go for Nokia's Qt branch) I can definitely see the concern, though. My main reasoning behind wanting a public hosting site is to foster [bazaar-style](http://catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/) development as much as possible, and to avoid allowing a small team to be able to control all development on a given codebase. Basically, I want each user to have full control over his/her branches. (being able to create wiki pages, issues, etc. just for that branch) Still, we may be able to find a way to achieve this without completely separating project-style and branch-style organization in EPIC... particularly, it seems that issues, wiki pages, and possibly even forums should be per-`branch` constructions, though we probably want wiki pages to also be possible in a `project`. (separate from that project's main branch) I think that basically a `project` should be no more than an encapsulation of a team, a wiki, and a collection of related `branches`; `branches` should then contain all the stuff that `projects` currently do. However, there's still some questions here... should `projects` be necessary? Does a new `project` need to be created if a user just wants to push a branch for some quick hack he tossed together? Also, what's the procedure if you want to fork an existing `project` (not just a branch) and create an entirely new project based on the old code?
Task #26 (Evaluate maintaining 2 separate forks for in-house project management and publicly-hosted project management) revision 3: Hmm... What kind of features? Because, I think that it might be possible to alter the paradigms enough that EPIC could work in both deployment scenarios. If we define a `project` to encompass all branches of the main repo, then, logically, `branches` fall neatly into place. This approach has the benefit of making the branches of a project logically contained within that project (personally, I *hate* github & company's lack of differentiation between somejoe/Qt and nokia/Qt... somejoe/Qt might be the better branch, but it only adds to confusion when all I want is Qt), and it turns the publically hosted version into configuration, rather than a separate code path. (The hosted version would have 'detailed branches' as opposed to the standard internal site's 'simple branches'.) Plus, enabling pull/fork functionality on an internal site is, actually, a nifty feature; it could be useful inside a self contained team, possibly combined with some code-review procedure. I really don't see a reason not to build a new paradigm out of the feature sets of both. It hasn't been done before (that I know of), but it seems to make sense in my head. I'd like to see a list of the 'incompatible' features between the two, so we could look at coming up with solutions to them explicitly. (I don't think there's really much incompatibility. At least, not in a direct sense. Most are features that aren't wanted, or different from what's expected. Internal sites don't use X, Y, and Z... hosted solutions do... then again, are any of the hosted solutions available to be run as internal sites? Is there any support from the project for doing so? My current understanding is that none of those sites are designed to be user deployable...) I dunno, that's my $.02

Wiki

Development (revision 2 by whitelynx): Added link to test site.
Overview (revision 18 by whitelynx): Added the Contact section.
Design (revision 7 by whitelynx): Ditched Account in favor of separate User and Team models, added Role, RolePermissions and UserTeamMembershipRole, and reworked several smaller things.
Design (revision 6 by whitelynx): `license_text` is more descriptive than `fulltext`.
Design (revision 5 by whitelynx): Changed `UserTeam` to `UserTeamMembership` to make it a bit clearer what it represents.
Design (revision 4 by whitelynx): Only teams should be able to own Projects.
Design (revision 3 by whitelynx): Added License model, decided what to do with repositories, rearranged things a bit, and added some more comments.
Design (revision 2 by whitelynx): Added `owner` field on Project.
Design (revision 1 by whitelynx): Created the Design page.
Overview (revision 17 by whitelynx): Added a link to the Design page.

Source

[pubhost] r437: Corrected CSS vertical-align declaration.
[pubhost] r436: Corrected 'overflow' declarations in CSS.
[pubhost] r435: Another important TODO item.
[pubhost] r434: Updated TODO file with latest items. Still needs to be pruned.
[pubhost] r433: Added template context processor to add the DEFAULT_FROM_EMAIL setting to the context, so we can refer to it in templates.
[pubhost] r432: Corrected submit buttons on register and change password forms, and made the registration complete page use the correct settings for the current site.
[pubhost] r431: Submit dialog forms using AJAX and reload the current page when done.
[pubhost] r430: Remove trailing slashes from wiki page URLs, since that breaks the Edit button.
[pubhost] r429: Moved modified and modified_string into Path, and changed them to use latest_revision. Also, reworked BzrPath.latest_revision to actually work.
[pubhost] r428: Removed old unused BzrRevision class, updated Revision to use the bzr revision object, added committer, timestamp, timezone, branchnick, parent_ids, and is_merge to Revision, made branch URLs and names slightly more robust, and added an error message to getPath when we can't match the path.
[trunk] r294: Fixed error using @login_required.
[trunk] r293: Don't show the 'New Issue' link when the user doesn't have the appropriate permission, and don't send people to the login page if they're already logged in.
[trunk] r292: Added bulk_entry template in preparation for actually implementing bulk entry.
[trunk] r291: Reformatting to match PEP 8. Wow, that was a lot of work.
[trunk] r290: Added inline Setting modification in Project admin, and fixed more code style issues.
[trunk] r289: Added get_absolute_url() to Project, and fixed code style to match pep8.
[trunk] r288: Removed some unused imports, and fixed code style to match pep8.
[trunk] r287: Added README for the Instinctual theme.
[trunk] r286: Changed icon for Tasks to the 'notice' icon, since 'check' is used for when an issue is closed.
[trunk] r285: Added issue type icons for each issue in the Issues list.