On Fri, Feb 6, 2015 at 8:24 PM, Thomas Güttler <h...@tbz-pariv.de> wrote:

> Hi,
>
> we want to make the changes in our applications better visible for our
> customers.
>
> We use several git repos:
>
>  - foo_customer: Here settings.py lives. It is quite small.
>
>  - foo_core: Central part of our application. The same code gets used for
> several customers.
>
>  - foo_plugin_bar: Just an example. There are several optional plugins.
>
> Here is my current road map:
>
> A nice interface for the customer implies: The changes need to be stored in
> the database. This makes it easy to sort and filter the changes.
>
> The origins of the changes are the git repos. I don't want to show
> the customer our commit messages. I want a manual step from
> commits to ChangeLog. But that's ok. This could be optimized later.
>
> Use Case: A developer merged a feature branch into foo_core.
> He needs to create a ChangeLog. The ChangeLog gets stored
> into the git repo, but on the next deploy some tool reads
> the new changes and puts them into the database.
>
> ChangeLogs need to be tag-able: You can apply tags like
> "performance-improvement"
> "new-feature" "bug-fix".
>
>
> I searched the web, but could not find something like this.
>
> Before I start to code, I want to get some feedback:
>
> What do you think?
>

To me - it sounds like something pretty closely tied to your own
development process, branching policies, and customer relationships. I have
no difficulty seeing how this could be implemented as a Django app - and a
fairly trivial one at that - your average change log is really not much
more than:

class Change(Model):
    message = TextField()
    created = DateTimeField()
    change_type = IntegerField(choices=CHANGE_TYPES)

How do you handle your ChangeLogs.
>

Through a process that is completely unrelated to the commit process.

For me, minimising the number of customer communications is key. I have
difficulty getting users to read and comprehend the notifications I *do*
send them - sending them complete change logs would be overkill, and would
result in important messages (like YOU NEED TO UPDATE YOUR ACCOUNT SETTINGS
OR THINGS WILL STOP WORKING) being ignored. As it is, these messages are
often ignored, and I need to follow up with individual users.

My audience would gain nothing from a fine grained commit log telling them
about every bug fix or performance improvement. They just want the system
to work. If it doesn't work, they email me, and they'd like to know when it
is fixed. To that end, I might not even send out a notification for a new
*feature*, unless that feature is something that has been requested by
them, or it will impact on the way they're using the system.

Lets be clear, though - I'm not saying your approach is *wrong*. I'm just
saying it wouldn't work *for me*. You know your own users/customers better
than I do.

Yours,
Russ Magee %-)

-- 
You received this message because you are subscribed to the Google Groups 
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to django-users+unsubscr...@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/django-users/CAJxq849c2_W-kWxn1jRkmk87S6P6sj4_m2uC9KcBAnnhUM5PHg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Reply via email to