Announcing the First GForgeNext Beta

Today we are announcing the immediate availability the first GForgeNext beta. With GForgeNext we are taking what we have learned about project collaboration over 15 years and distilling it down to what you need right now.

Who is GForgeNext for?

This first beta is just that, a beta.  GForgeNext is a redesign of some of the key features we offer in GForge Advanced Server.  In other words, it is a minimum viable product (MVP) and it offers the following features:

  • The ability to create an unlimited number of private projects and quickly send project invitations to your team.
  • Git Support
  • A basic ticketing system that supports a kanban view and Git integration.  You can quickly attach screenshots and documents via drag-n-drop.
  • Team Chat which is integrated with Git and the Ticketing system.  Chat also support drag-n-drop of any file including rendering support for images and YouTube videos.
  • A REST-ful API
  • User’s can manage their own todo list across all their projects.
  • The ability to control who has access to various parts of your project.

We are offering GForgeNext absolutely free*, the only thing we require is that you give us feedback on a regular basis. To make the feedback loop easy we provide a feedback button on every page that allows you to report bugs and to share ideas and enhancements.

Ideal organizations will run projects with 5 or more team members and, while not required, we’d love to see some organizations in or around Iowa to open up the possibility of collecting onsite feedback.

Are you interested?  Please request access now.  Those users given access to this first beta will be able to invite other users to their projects.  All users participating in the beta, not just the leads, will be able to create their own projects.

Still not sure?  Further below we share some screenshots of an actual project using GForgeNext.  If you still have questions please send them to feedback@gforgegroup.com.

* We really do mean free.  The only caveat is we haven’t determined how long GForgeNext will be free but we do know it will be for at least two years and that customers that join us during this first beta will receive steep discounts whenever we do begin charging for access.

Who Shouldn’t use GForgeNext

GForgeNext’s current features are stable and can be used as-is with the expectation these features will always perform as expected.  In fact, we are using GForgeNext internally.  That said, there are some features we have planned that haven’t been implemented yet.  These features will be released throughout the coming year but if you require them immediately then you should not use GForgeNext:

  • Workflow support in the ticketing system.
  • Peer code reviews via Git
  • SVN support
  • A document management system
  • Team Chat in a separate window with support for multiple projects.
  • Custom roles and access control – GForgeNext currently offers the following pre-defined roles: Lead and Contributor but eventually you’ll be able to add new roles and customize their level of access.

For now, GForgeNext is only offered as an online service so customers who require the ability to run GForgeNext on their own, internal network will need to wait until later this year. Current customers using GForge Advanced Server will receive regular email updates on the progress of GForgeNext and we will share the date of the first stable release as it approaches along with guides for planning your upgrade.

GForgeNext Screenshots

Project Homepage

Project_Home_-_GForge_AS_-_GForge_Next_and_GForge_AS_by_GForge_Group___GForge_Discussions

Navigation via MegaMenu

Project_Home_-_GForge_AS_-_GForge_Next

Project Administration

Team_-_GForge_AS_-_GForge_Next

Browsing Tickets

GForge__6_4_2__Remaining__-_GForge_Next

Kanban View of Tickets

GForge__6_4_2__Remaining__-_GForge_Next

Editing a Ticket

__8999___Commit_M____-_GForge_AS_-_GForge_Next

Git Support

Git_SCM_-_GForge_AS_-_GForge_Next_and_GForge_AS_by_GForge_Group___GForge_Discussions

API Documentation

Entity__Trackeritem_-_GForge_API_and_GForge_AS_by_GForge_Group___GForge_Discussions

Git Workflow in GForge

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:

GForge_AS_by_GForge_Group___Projects___GForge_AS___Tracker___GForge___Edit_Tracker_Item

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.

GForge Next – The API

A couple of weeks ago, Tony shared some screen shots of GForge Next, and talked about how we’re designing it to Get Out of Your Way.  Today, I’d like to talk about the other end of GForge Next – the API side.

We’ve Always Had An API

It’s true – the current GForge has an API, and it has for over ten years.  But it’s……not awesome.

If you have ever worked with SOAP services, then you know they can be overly complex, verbose and yet inscrutable.  Not to mention it can be fragile, especially between different platforms (I’m looking at you, Java/Axis/Axis2/XFire).

But the real flaw in our SOAP API is that is was bolted on to the existing code.  There’s quite a bit of logic shared between the GForge UI and the SOAP API, but also some duplicate code, so the API won’t always act the same way as the good old web UI.  As we continue to fix bugs and add features, it continues to be an extra effort to maintain these separate code modules and keep them working the same way.

Now With 100% More REST

Like everything else with GForge, we are our own worst critics, and our own first users.  So it was easy for us to decide that to be useful, the API had to be an integral part of the system.  The entire GForge Next UI runs against the API.  Logging in?  API call.  Getting your list of assigned tasks?  API call.  When we use GForge Next UI to accomplish tasks, we’re also automatically making sure that integration via the API will work for all of those use cases.

For wire protocol, we chose REST (like pretty much everyone else these days).  JSON + HTTP (GET, POST, PUT, DELETE) is a pretty simple, readable and capable combination, and it aligns nicely with the other parts of our technology stack (like AngularJS and Bootstrap).

The API is even self-documenting thanks to code-comment blocks in the underlying services and our /apidoc endpoint.  The API docs include all the entities, methods, parameters and even example input and output.  As we continue to add and change the API , the docs are automatically up to date.

Selection_291

For the most part, we submit data to the API using the same JS objects we receive from it.  That way, we can take an object from a list of values, assign it as a property on another object and submit it.  Super-simple on the client side, and pretty easy on the server as well.  But for external integration, it’s not so great.  Requiring callers to fetch a bunch of lists and sub-objects in order to properly craft a request makes the API less usable and more prone to invalid requests.  So, for most requests, we will accept any of the following values for sub-objects (like a project, a status, the user, etc.):

  • The “official” JS object for that type (retrieved from the API)
  • The ID or alias for the object, as a number or string value.  For example, ID 2000 or the short name mtutty for a user.
  • A JS object with an ID property, with the same value as the above bullet.

In general, the API back-end will work pretty hard to figure out what value you’re trying to use, and go find it based on the ID or key value submitted.  We also support vanilla FORM POST semantics, so that regular HTML forms, curl and wget requests are easy to do.

Complex Can Still Be Simple

So it’s pretty easy to create a basic CRUD API for a set of related tables.  The current GForge Next database has about 137 tables, which is a bit more complicated.  Add to that the fact that most realistic use cases (including our own UI views) are going to need multiple types of data, and using the API just went back to difficult and confusing.  Well, maybe not.

Largely for our own needs, we started adding related data as optional for many API calls.  By adding “rel=xyz” to a GET request, you can ask the GForge Next API for additional data that is related to the entity (or entities) you’re requesting.  So for example, GET /api/user/mtutty/details?rel=projects,activitylog includes the most-used projects and most-recent activity records for me.  That’s all the data needed for the user profile view, in one call.

Don’t need all that extra stuff?  Don’t include the rel, and you can get the payload down from 3.6K to 963 bytes.

How About Some Examples?

Here are a couple of ways we’re already using the API (outside of our own UI) to keep project data and knowledge moving, even when things are happening outside of GForge.

Build and Deployment Activity – We use Jenkins for CI/CD (and deploy GForge Next several times every day).  Whenever builds start or fail, or whenever a deployments starts or ends, we use the REST API to log an activity record.  This is visible in the Project Home page activity view and in the project chat room (which is where we see it most of the time).  Now as we’re working on tasks, we can see not only what tasks other people are working on, and their funny cat pictures, we can also see our build kicking off, and code going live, in real time.

GForge_AS_by_GForge_Group___GForge_Discussions

Customer Feedback – First Dozen users will notice the green “Feedback” tab on every page in Next.  That tab submits data to a separate Tracker called, well, “Customer Feedback”, using the API.  Technically it’s part of our site but we have made a conscious effort to keep it separate from the AngularJS application that contains the rest of GForge Next.  The Tracker template will be available in GForge Next, and eventually we’ll make the widget available too, so customers can collect feedback from users directly into their GForge Next project.

tbibbs___my_-_GForge_Next

Where To Go From Here

While we are excited for the new REST API in GForgeNEXT what really excites us is the creative ways developers will use the API.  Because the API is new and will continue to develop, we really hope you consider signing up for early access to GForgeNEXT. Those requesting early access will can expect the beta to begin officially over the next couple of weeks which will include immediate access to the API.

Getting Out of Your Way

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:

New_Item_in_GForge_-_GForge_AS_-_GForge_Next

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:

GForge__First_Dozen__Remaining__-_GForge_Next

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:

GForge__First_Dozen__Remaining__-_GForge_Next

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:

hectorpizarro___my_-_GForge_Next

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:

GForge__First_Dozen__Remaining__-_GForge_Next

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:

__10620___Update_____-_GForge_MVC_Library_-_GForge_Next

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.

Maslow for Startups

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

Maslow's Hierarchy

A simple version of Maslow’s Hierarchy

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.

 

 

They Really Can’t, But You Can

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.

GForge v6.4.1 Released

Today we are happy to announce the immediate availability of GForge Advanced Server v6.4.1.  This is a bug fix release that also includes minor enhancements.

Download GForge Advanced Server v6.4.1 Now!

New Features in GForge v6.4.1

  • Docman – We made a few updates to Docman in 6.4.1 including the ability to mass upload documents by uploading a single, compressed file (.zip, .tar, .tgz, .etc).  You can also quickly restore a prior version of a file to the newest version while retaining the complete version history.  Finally we’ve added better logging, particularly when files and folders are deleted so administrators can identify what was deleted and who deleted them.
  • Tracker – Project administrators can now manually add and remove user or user groups from monitoring a Tracker or Tracker Items.  Also any custom tracker fields can now be added to the “Quick Filter” when browsing Tracker Items.
  • Project Templates – Before 6.4.1 you could configure GForge to auto approve projects.  We’ve now added a better level of control by allowing site administrators to configure which project templates require projects to be explicitly approved or which templates can employ the use of auto approve.
  • Debian – We now support Debian “Jessie” in addition to the latest versions of CentOS and RedHat Enterprise Linux
  • Discussions – Images added to discussions in the “forum” view are now rendered in-line just as they are in “chat” view.
  • SSO & LDAP– We’ve streamlined the user experience for customers using SSO and LDAP

The Gory Details

GForge v6.4.1 includes a number of bug fixes and security updates. For the full details of this release, please have a look at the Complete GForge v6.4.1 ChangeLog

Download GForge Advanced Server v6.4.1 Now!

Follow

Get every new post delivered to your Inbox.

Join 1,638 other followers