While GForge has support for CVS and SVN, most of our customers have moved on to Git. What gets buried in that integration is our customers have a choice on how to use Git and they can have GForge enforce some basic rules. Today we are going to address implementing a common Git workflow in GForge.

For small projects with one or two developers you may not require workflow and in these instances you can happily clone, commit and push changes right to your master branch. GForge has been engineered to accommodate even the smallest of projects so we support this model just fine. Organizations with larger projects don’t want developers pushing code to their master branch because it typically represents the current, stable build. Instead they opt for a review process of new code that is then systematically reviewed and tested before being pushed to master. GForge’s Git integration supports this and to show how it works we’ll be using a real-world example.

Internally our work uses the same workflow for new development work and bug fixes:

1. Task is created
2. Task is prioritized and eventually assigned to a developer by a project lead.
3. Developer does their work
4. Developer requests a code review
5. Code review is performed and, if successful, is published for testing
6. QA confirms the code is working through a series of tests.

To support this, our tasks have the following workflow through statuses:

1. Awaiting Assignment
2. Accepted
3. Ready for Merge (Code review)
4. Fixed: Test for Release
5. Fixed: Closed

The steps above represent the happy path for all tasks. We have additional workflow rules to cover the not-so-happy path for things like failed code review or failed test results. To make this work in Git we have the follow rules:

1. Our master branch in Git is always our last stable release. So while we are currently working on GForge v6.4.2 the master branch currently holds a snapshot of v6.4.1.
2. We have an integration branch called gforge-next. This holds all of the work that has gone through the above steps for v6.4.2
3. Each task assigned out get it’s own work branch, i.e. #1234-bugfix-of-some-sort. These work branches hold only the code required to satisfy the work described in a single, atomic, task.

So naturally there needs to be a way for a workbench to get into gforge-next and then eventually into our master branch. To handle this our internal tracker has a custom field we’ve created called “work branch”. When a developer starts work on a new task they will create a new work branch from gforge-next and give it a name i.e. #1234-bugfix-of-some-sort. When they commit their work to that work branch they will push it and then move task #1234 into “Needs Merge” status. Another developer will checkout the work branch and perform the code review. Assuming the code review is accepted, then the developer who did the code review will merge the work branch into gforge-next. For all the other tasks in a given milestone this same process would happen. Here’s a screenshot of a ticket awaiting a code review:

As that is happening we deploy the gforge-next branch to a server where we do our testing. This means that as tasks hit the “Fixed: Text for Release” status, QA will grab the task and test the task works as expected. Once the tests pass then the task is marked “Fixed: Closed”.

Finally as we close out a milestone, say completing v6.4.2, once all the tasks have been marked “Fixed: Closed” we will then prepare a new GForge release by merging gforge-next into master and then tagging that state of master with the version number being released. Incidentally, once we have updated master we will then go in and remove all the work branches and then begin work on the next major milestone.

As you can see, we place no restrictions in how you use Git and you can implement any Git workflow you want. If you have questions regarding this feel free to post a comment below or customers can send questions to support@gforge.com.

When I talk to customers about GForge, I often describe it in terms of parenting. For product managers, their products are their children and good parents see all the untapped potential alongside any rough edges. Like parents, product managers often spend a disproportionate amount of time playing up their products strengths while downplaying those rough spots.

GForge and nearly every product in our space shares a common flaw: we get in the way too much. Product managers fantasize about how much customers use their products and, while understandable, sometimes the measure of a great product or feature is how much it gets out of our way. Let’s explore this concept with a concrete example.

As we’ve been redesigning GForge, everything related to the customer experience is on the table. Over the past few weeks we’ve been finishing up how leads, PMs and individuals manage their work. For most organizations this means multiple projects with competing priorities fighting for engineering time. This process usually goes through a review by leads or PMs resulting in work being dished out to team members who then have to figure out how to factor those competing project priorities to build their work queue. Worst yet, this process often happens multiple times each week with the team members organizing their queue on a daily basis. Compounding things, each organization has a toolset that is meant to facilitate some or all of this process and here-in lies the problem. While the tools often facilitate organizational process, they are often clunky and impose team members to do interact with the tool more than needed. This is the exact sort of problem GForgeNEXT is trying to fix.

So what are our goals in the specific case

1. It has to be easy for leads and PMs to prioritizing work ahead of assigning tasks to team members.
2. Leads and PMs want to quickly prioritize team members tasks, many of which, reach across milestones or other projects. To be clear, we are talking about prioritizing work across projects and milestones where tasks, in many cases, have been given the same priority.
3. As an alternative to #2, above, some organizations prefer to give team members the flexibility of prioritizing their assigned work across projects and milestones.
4. Leads and PMs want to monitor an individual’s contributions and tasks (again, across projects and milestones).
5. Team members want to work through their queue without having to constantly refer to to their list.

To drive home the need of tools needing to get out of the way of teams let’s show how GForgeNEXT addresses this.

Prioritizing and Assigning Project Tasks

Admittedly, GForgeNEXT isn’t doing anything truly revolutionary in this area. The fact is to prioritize and assign work on a project, you simply can’t get around building a list and then setting the priority. In fact, you’ve always been able to do this quite well in GForge but we did add a few wrinkles to make this easier. First, when building your list, we’ve made it easy to quickly add a tasks:

As you see, you can now save and quickly navigate to add additional tasks eliminating the step of going back to any list. Once you’ve built your list you can further refine the priority and assignment of tasks:

One minor feature we added is the ability for team members quickly add a task to their own queue. While browsing tasks they can click on the star icon which will a) assign the task to the team member and b) add it to the end of their current queue:

Probably the biggest enhancement to the task list is that they are all part of a polling loop to reflect external changes. That means if you are working through prioritizing project work in a phone call or meeting one person can change the priority (or status, assignee, etc) and anybody else viewing the same page will see the changes.

Prioritizing Work Across Projects and Milestones

To this point we’ve shown how to manage tasks within a project, however, if you are in an organization with multiple team members working in a growing project portfolio you need to have a handle on how that work is prioritized work across projects with competing priorities and deadlines. This is equally true for team members who may have the flexibility to make their own decisions on how to prioritize their tasks across projects.

In GForge you could already view your assigned work and even manage that work within your own queue. While the feature is there and it works GForgeNEXT simplifies all this:

What you see above really addresses three basic questions for any given person:

1. What has this person been assigned
2. What are they currently working on
3. What have they completed

If this sounds familiar, that’s because this is what nearly every “status meeting” in nearly every organization has covered for decades. “Status Meeting”, “Stand-up Meeting”, call it what you want, those are the three basic nuggets of information they are all after and they account for significant productivity waste.

When viewing an individual’s queue, GForgeNEXT gives you the answer to those three questions. See, access to an individual’s queue is based on the relationship of the viewer, specifically, leads and PMs can now monitor and optionally manage their team member’s queues. Obviously this also implies users can manage their own queues and all of this is done by dragging cards between the Assigned and Queue columns or moving cards within the Queue column to set the order.

Finally, just as when browsing tasks, when you are viewing an individual’s queue, any external changes made either by the individual or a lead/PM will be automatically reflected .

Working Through Your Queue

Once the lead, PM and the individual have setup their respective queues team members can begin work. What’s important here as while the queue exists we have tried our hardest to make complete taskseffortless. For example, you can quickly view your queue fight from the menu in GForgeNEXT:

From there, as you complete work in your queue you can simply access the next item using the What’s Next button which will save your work and take you to the next task in your queue:

Again, Let’s Get Out of Your Way

As I’ve said before, we don’t pretend any of this is truly revolutionary but as we continue product development on GForgeNext we continue to not only listen to our customers but figure out how we can reduce friction so your teams can focus on getting work done. Regardless of whether you use GForge or not, let us know how your organization manages work and if what we outlined would fit your organization. Finally, If you’d like to take a closer look at GForgeNEXT we invite you sign-up for our beta program which will be launching soon.

Abraham Maslow was a psychologist and professor. He designed this great hierarchy of human needs:

Basically, it says we need to breathe before bothering with staying warm. And we need to eat before worrying about having any friends. And we really can’t spend any time following our dreams until we’re clothed, fed, warm, have some friends, and overall feel pretty good about ourselves.

It seems natural to me that product-driven companies would follow a similar sort of hierarchy. There’s a fairly common progression of needs that a company must satisfy in order to survive, grow and succeed. In trying to figure out which GForge features you’ll really need, and in what order, I’ve come up with these buckets and given them catchy Greek-themed names. We’re using these buckets to guide our feature deployment for GForge Next, so that we meet the needs of new users easily, and give them more features as they begin to need them.

Group 1: Atlas

Context

The most basic level of business development. This model depends heavily on large efforts by a small group. Their roles, interactions and dependencies may be somewhat defined, but most processes are still ad-hoc, and are created, revised and discarded based on immediate needs.

Motivation

Generally, boot-strapping – that is, getting to market on little (or no) financial budget. Initial product/service delivery to see if the business model is viable, or trying to bring in the first customers to fund further expansion.

Values

Atlas groups tend to:

• Spend Time/Effort instead of Money

• Be Flexible as opposed to Repeatable

• Depend on A Few Heroes instead of Divide and Conquer

• Prefer Simple Process over Robust/Complex Process

Needs

1. Task/Issue Tracking – First and foremost, a persistent list for who is doing what. The group is very small, self-directed, and self-organizing, so features like metadata (e.g., severity, milestone, priority, workflow by status) and access control are not important.

2. Version Control – Whatever type of product (software, design/creative/mkting, manufactured goods, etc.), there will be some kind of source code, documentation, images, or other output to be kept safe and trackable over time.

3. Project Chat – A live, persistent and searchable scratchpad for quick discussions, news and humor without having everyone leave their desk.

Group 2: Vulcan

Context

The first big change in team organization. Initial product may be out, customers calling for support, feature requests, etc. Team’s focus is still more tactical, day-to-day, but the group is growing to handle success. Working some things in parallel, especially support tasks vs new features.

Motivation

Leaders are focused on finding more customers, and keeping current ones happy. Product delivery functions need to be automated, to allow tech staff to focus on what instead of how. Customer service, support, operations and development tasks need to be centralized so that everyone can stay focused. Knowledge needs to become somewhat portable so that team members can be added, back-fill others and cover breaks/days off.

Values

Vulcan groups:

• Place more premium on Time as money starts coming in

• Need Repeatable processes that may still change often

• Feel torn about moving key staff to bigger and better things

• Start seeing many exceptions to what used to be simple processes

Needs

1. Document Management & Wiki – Create a culture of portable knowledge early, and staff will maintain docs out of habit. This makes it easier for players to switch positions, cover others during crunch times.

2. Standups, Sprints & Milestones – Start to group tasks into small projects and track overall completion. Allow different milestones to start competing for resources. A first step toward portfolio management.

3. Ubiquitous Search – Make it brain-dead simple to find that thing you saw a month ago, and share it with others.

 

Group 3: Prometheus

Context

Things are really under way. Founders may be somewhat disconnected from daily operations. With monthly cash flow ensured, leaders begin to reach out to partners, competitors, upstream/downstream value chains, trying to expand customer base and/or find new features/products to add. This phase usually includes the first serious wave of new hires who were not present at the founding of the org. Cycle times get larger and more unpredictable as internal process and technical dependencies begin to weigh on the system.

Motivation

Staying agile and responsive is even more important here than in previous phases. Partners and competitors begin taking the product and company seriously. This means real contracts, real accounts won and lost based on delivery. At the same time, the heroes from Atlas phase are no longer able to touch everything every day.

At this point, the steering function has become as important to success as the rowing function. Management needs to be able to see into the future, predict outcomes, plan for contingencies.

Values

Prometheus groups:

• Start to segregate knowledge to insulate groups from information overload and keep them focused.

• Develop a strong need for metrics and measurement, instead of steering by feel.

• Want standardized processes to allow for apples-to-apples comparisons over time.

Needs

1. Robust Roles and Access Control – Organize things according to company structure, lines of business, etc. Begin to control access by org and project membership. Allow selected people/groups to collaborate from outside the company.

2. Workflow and Audit – As complexity and required quality levels both grow, more detailed workflow and audit trails are required to keep things moving quickly.

 

 

Read this (now deleted) blog post by a dev at Oracle: No, You Really Can’t

There is so much wrong with that post. But I’m in a hurry and don’t have time to put down 3000 words deconstructing Oracle’s entire business model and world-view. Instead, I’ll just explain how we do the exact opposite.

GForge offers up the entire(*) code base for customers to examine, scan, and even change. We maintain customer-accessible Git repositories (on gforge.com, of course), so that customers have constant access to the current released version (that would be 6.4.1) and the version that’s in development, which we also deploy and use ourselves every day at gforge.com.

GForge customers can maintain their own Git repo (with, say, custom theme elements, or code to integrate with a custom database, or whatever), pull from ours, and keep up to date with new features, security patches and everything else we come out with.

As if that’s not easy enough, we also regularly send patches to customers to fix specific problems they report, even if they’re not at the current release version. You don’t have to wait six months for the Oracle mega-patch, and get 3000 other changes you didn’t ask for.

Lastly, customers can (and are encouraged to) send us patches for things they have fixed or improved. When Tony and I were GForge customers, we did this on a couple of occasions. You’re welcome.

Every day, we try to treat customers the way we like to be treated. Customer access to the source is just one reflection of that value.

PS – As if on cue, here’s a great example of why you don’t want to wait six months for the vendor’s bug fixes.

*Okay, okay. There’s one file that we encrypt, that handles validation of the customer’s license key. I know Richard Stallman is pro-actively spinning in his grave, but if you really want to see what’s in there, I’m sure we can arrange something.

We recently gave an early preview of GForge Next which included a chance to sign-up for early access to GForge Next. Today we are keeping the ball rolling by sharing new screenshots of our new Kanban feature, tasks and chat. Please follow along as we share our ideas and you are encouraged to help us hit the mark by providing feedback either in the comments below or by sending a note to feedback@gforgegroup.com.

Kanban

These days Kanbans are a dime a dozen, however, what is unique about our approach is that we are able to provide the convenience of planning with Kanban without making significant changes to our current codebase. After all, the Kanban is a more visual way to manage Trackers in our current system. With Kanban we are leveraging that existing information and presenting in a way that makes planning easy:

The above screenshot hasn’t been implemented yet it gives a concrete idea of how we are approaching Kanban. By default we will show all the statuses in your project as columns and inside them are tasks associated with each. Changing the status of a task will be as easy an dragging a task from one column to another. Taking things a bit further, you will be able to switch to a view that shows your tasks in a Kanban view grouped by the assignee:

Chat

For over a year we’ve made the case that chat shouldn’t be something you bolt on to your existing collaboration suite using a third party tool, and API and duct tape, rather, it should be an intrinsic part of any project. While we’ve done this quite well in our current product, we’ve raised the bar by making chat available as you move in GForge from one project to the next:

As you can see in the screenshot above the project’s chat room is made available in a panel that you can hide easily. GForge Next will support all the features our customers gotten used to in our current product including project activity (commits, updates to tasks, continuous builds, etc) with the project discussion. If you look close, you’ll also see an updated version of the new menu in GForge Next that will let you quickly jump between projects easy.

Tasks

Our current version of GForge has had bug and task management for years and we’re finally redesigning all aspects of how you work with tasks in GForge Next:

While this is a simplified version of what we plan on delivering, it shows the direction we are headed. Gone is the old table-based tracker item browse and instead you get a simpler, more powerful replacement. While browsing tasks you will be able to quickly change the most common field such as assignee, priority and status and once updates are made the page will reload the data to owner the selected filters. Future iterations for browsing tasks will include some additional features:

• The ability to edit a task right on this same screen.
• Mass update of tasks
• Searching and filters

Adding tasks has also been improved to be simple and clean:

For existing customers, one of the things that should jump out at you is the tagging feature. This has always been a part of our current offering but using tags has been cumbersome and thus, infrequently used. GForge Next will make pervasive use of tagging. As you start typing a new tag, we will give you an autocomplete list of matching tags that have already been used on your project. Additionally we have made it much easier to add a number of new tasks with the new “Save & New” button that will keep you from having to go back and forth between browsing tasks and adding task.

We are exploring the idea of making this screen available as part of the browse page so you can add tasks without leaving the browse page. Similarly we hope to have similar way for adding tasks when you are in the Kanban.

Again, these are just a few of the concepts we are working on in GFoge Next. Let us know what you think by either posting a comment below or sending a note to feedback@gforgegroup.com. In the meantime, stay tuned for more updates…

This is a quick note to let our customers know we now offer support via a live chat. We are providing this by leveraging our existing chat feature in GForge . You can still manage your support tickets via our online system, however, we think our customers will find live chat as a great alternative. Also, we should note we offer live chat support in both English and Spanish

Join GForge’s Support Live Chat Now!

This is an exciting time for us at The GForge Group. As we hinted in our preview of the upcoming GForge v6.4.0 release we have been working on a re-design of GForge and we’re happy to give you a glimpse of that work and give you limited, early access when the first version is ready.

To help set the table, we want to share our goals with this first release of GForge Next.

• Provide a minimum viable product (MVP) to new users looking to host their project. The current version of GForge has a number of rich, deep features and it would be unrealistic to launch them all at once completely redesigned (especially with no customer feedback). The MVP will include:
  • User and project registration
  • A user’s profile page
  • A project’s summary page
  • Project chat room for collaboration
  • A single tracker for tracking enhancements, bugs and tasks
  • Working Git repository integrated with the tracker
  • A fully documented REST-ful API
• Make the easy tasks easy. Our current design has served us well for a long time but there are too many steps to accomplish simple tasks. In the same vein, we need to make harder tasks easier. Or goal is to reduce the reliance on documentation that our current system requires.
• Collect feedback from early adopters on the redesigned system. We plan on doing this by providing a convenient feedback icon on all redesigned pages as well as reaching out to our customers in a variety of ways (email, online meetings, etc)
• Vet the decisions we’ve made on our technology stack. For the geeks out there, we are using a mix of tools from our old stack and newer technologies:
  • Composer
  • Angular
  • Doctrine
  • PostgreSQL
  • PHPUnit
  • Jenkins
• Add the beginnings of a true SaaS model. Right now GForge is only available via download. Moving forward we want to offer both SaaS and downloadable options. This also means our SaaS implementation make new features and bug fixes immediately available through our automated build and release system.

Before we share the first screenshots of GForge Next, we want to invite all of you to sign-up for early access today. While early access will be limited, we do plan to open it up again as we approach beta. Finally, we want to hear from you so please post questions below or feel free to send questions or feedback to feedback@gforgegroup.com.

Screenshots

“G” Mega-menu

Knowing how screen real estate is a premium, we wanted to provide a better way for users to move between projects and to quickly access common features. This screenshot shows the “G” Mega-menu prototype which ditches persistent left and top navigation for a menu that is accessible by moving your mouse over the “G” in the header:

Project Summary

The project summer is a landing page and this is a first stab at it. There will likely be significant changes however, this shows some of the things that are possible.

 

The working prototype above is showing two simple graphs that are completely rendered in JavaScript complete with mouse-over animations and drill-down support. The beauty about much of the work you see above is we have all that data currently, we

Git Support

We will be providing Git support in the initial release but, for now, we don’t support web-based browsing (it is coming). However, we do want to show the main Git landing page:

As you can see, we coach users through the process of not only learning Git but also how they can use the integration we provide between Git and the Tracker. Full Git support is there so you will be able to follow the instructions on that page to do your clone as well as tie commits to tasks, we just haven’t released the browser-based navigation of your Git repository yet.

Browsing Tasks

Kanban

This prototype shows how we were able to quickly render the Tracker into a Kanban format. We have lofty goals for the Kanban but our initial goal is to provide drag-n-drop capability to move tasks between two statuses and to quickly add new tasks to the view.

We will be providing short, screenshot updates on a weekly basis here so please keep an eye out and in the meantime post any questions or comments you may have below.

We have been pretty quiet this summer regarding the work progress we’ve made on GForge but that is going to change dramatically. We will be making two big releases before the end of the year and in the coming weeks and we’ll be sharing all the details here.

The first big development is the work we’ve done on the next generation of GForge. This past spring we started a complete redesign of GForge taking care to include the features our customers have grown to love while ensuring a pleasurable and efficient experience for our users. We will be talking more about the specifics of our redesign in the coming days and weeks so please check back.

For now we want to share some of the new feature in the upcoming v6.4.0 release. We don’t have a firm release date yet but expect an October release. While working on v6.4.0 we made some tough decisions on what features deserve to be added now verses tackling them in the redesign effort. To that end, we only added features that will have lasting impacts on your projects. So what can you expect in GForge v6.4.0

Sprints

We have added native support to GForge Trackers to support sprints. Agile shops will get all the features they need to create and track their sprints. We have been using this feature internally for a number of months and here is a screenshot showing a list of sprints. It should be noted that Sprints can include tasks across all the Trackers in a project (e.g. Support, Bugs, Tasks, etc).

As you can see, our Sprints are date-based and run weekly but your Sprints can be tailored to meet a specific goal or milestone. In the image above we provide a quick status of the sprint along with how complete it is. Over time this list can become quite large so you can filter your sprints with intuitive options like “Not Started”, “In-Progress” or, our favorite, “In-Progress or Not Started”:

Once you have your sprints created you can very quickly add tasks to the sprint using Tracker Item Browse where we have included Sprints in the filter and mass-update forms. Here’s how you can filter on a sprint:

Here is the mass-update feature using sprints:

Finally, what is a sprint if you can’t track its progress Each sprint gets its own burn-down chart to help project leads and project managers verify the team’s velocity toward the sprint:

Finally we have included sprints in the Tracker Query and export features so you can quickly create customized reports leveraging sprints in GForge v6.4.0.

Trove Improvements

The Trove in GForge may seem like an ancient relic however we dusted this feature off in v6.4.0 so that organizations can better organize their projects into a taxonomy that make tracking your project portfolio easier. If you aren’t familiar with the Trove, it allows you to define your own method for categorizing projects. For example you may choose to organize project by technology(e.g. Java, .NET, Microsoft SQL Server, Oracle, etc). Other real-world examples include tracking which projects are subject to United States export control laws or for assigning the re-use level a project has based on it’s maturity (i.e. documentation, testing, etc).

We’ve completely revamped the Trove administration screen making much more intuitive to work with while reducing the possibility of making mistakes:

As you can see from the screenshot above we’ve added a few new features:

• Easily move Trove categories around.
• Move one Trove category into another.
• Set the access level each category has. This allows GForge administrators to specify which Trove categories can be set by the project administrator versus those that can only be set by the GForge Administrator.
• You can indicate if the Trove category should be included when users perform site-wide or project-based searches.
• The updated tree structure shows your entire Trove map and allows you to quickly add new Trove categories. For the first time, you can now manage the top-level, parent Trove categories.

We’ve also updated the Trove to make it easier for project administrators to organize their project:

In the screenshot above you can see we’ve made it easy for project administrators to quickly add or remove their project to existing Trove categories.

Project Templates

One of the more powerful features of GForge has been the ability to set-up project templates so that new projects can be quickly and consistently created to use the features you value most in GForge. While you have always been able to create project templates that generate a default set of Trackers (with workflow), project-based chat, etc we recognized that organizations with a large set of project templates had a hard time finding them. With the improvements we’ve made to the Trove, there is now a new parent-level Trove category for project templates. This allows you to organize your templates any way imaginable such as by organization or department.

Here’s an screenshot of how GForge Administrators manage the templates in the Trove:

Once you build the striation for your project template, it appears when users create new projects:

Tracker Workflow

GForge has always allowed project leads to specify a workflow for tasks, however, the administration of the workflow was a bit cumbersome. We’ve made this a lot easier in v6.4.0:

Prior to v6.4.0 you had no visual indicators for which workflow transitions you’ve specified rules for (such as who can execute this transition, fields required to make this transition, etc). A gray circle indicates you haven’t added any rules to the corresponding transition and a blue circle not only indicates you have provided rules, if you hover over the blue circle it will give you a quick summary. This will make managing a complex workflow much easier your teams.

And Much More

In addition to the above, we have numerous other bug fixes and improvements. In fact we currently have over 300 updates. We’ll save the details of those for the v6.4.0 ChangeLog, however, here area a few more highlights:

• Training Videos: We have created a number of training videos and you can stay up-to-date as we publish them on our YouTube channel.
• All configuration settings have been moved from the files in /etc/gforge to the database. We now ship a convenient shell script that allows GForge Administrators to view and tweak their settings. Also, as part of this, we automatically rebuild the configuration cache so no more running “#>cd /opt/gforge && php ./bin/create_config_cache.php”.
• Added support for CentOS 7/RHEL 7.
• Added support for Debian 7. NOTE: while this works there are some RPM dependencies GForge has that aren’t covered by the Debian repositories. We will be documenting how to install GForge under Debian as part of a future blog post.
• Chat rooms are now URL accessible. This means you can share the chat room via email or link to it from another document. (NOTE: we’re exploring using this as a new support options for customers).
• Project searches now use GET instead of POST which means you can share the URL of searches with other team members.
• Added a configuration option to auto-approve projects. Great for organizations who host GForge on an intranet and who don’t want to explicitly approve projects.
• Added a configuration flag that allows GForge administrators to specify if Project Administrators can promote their project to a project template.
• mod_auth_gforge Apache module is now used by default. This means that role checking and ACL verification against the GForge database can happen over HTTP(S) with SVN and Git.
• Fixed a bug that prevented users from adding more than one SSH key to their GForge account.
• GForge now provides the same UI we give for pre-commit filters for post-commit filters.

GForge Next

As we eluded to at the beginning of this article, we will be sharing some exciting news on our redesign effort. We expect that to happen in the coming days and it will include screenshots of working code to show-off some of the big improvements we are making. We will also share a tentative timeline on when the first alpha will be made available as well as a general timeline toward the first beta.