[Replicant] How shall we Redmine?

Tue Oct 8 00:58:00 UTC 2019

Hello Replicants,

I didn't get any responses to this thread. If you have any thoughts on
any of these items, even if it is only one or two comments, please feel
free to share them. Also, no pressure to respond if you are busy or
don't have anything worth sharing.

In Solidarity,
Kurtis

Kurtis Hanna:
> Hello Replicants,
> 
> OSUOSL recently finished updating our Redmine to version 4.0.4. [0]
> 
> Now that it is completed, it might be worth it to have a discussion
> about whether we want to make a few modification to our now up-to-date
> Redmine instance since it is used so much by the Replicant project.
> 
> I should start by mentioning that I haven't interacted much with other
> project's Redmine instances and very well might not understand the
> benefits of doing things differently than Replicant has already done
> with our instance, so please accept my opinions below as humble
> suggestions only.
> 
> Here's a few topics that we should perhaps explore:
> 
> 1) Projects and Subprojects
> 
> In Redmine we can create Projects and Subprojects. Up until now we have
> only used a single Project which has the following modules enabled:
> Wiki, Calendar, Time tracking, Gantt, Issue tracking, and Forums. I also
> just enabled the News module on the Project, but feel free to disable it
> seems unneeded.
> 
> Denis made a subproject of our main Replicant project called 'Replicant
> infrastructure' in order for us all to see what a subproject in Redmine
> looks like. We can use it as a temporary sandbox to test it out. Do you
> guys think that having subprojects would help us organize ourselves
> better on Redmine?
> 
> One concern I have about it is that, especially with the wiki module
> enabled on subprojects, it would lead to data fragmentation.
> 
> For instance, I'm not sure if any problems are solved by having this wiki:
> 
> https://redmine.replicant.us/projects/replicant/wiki/ReplicantInfrastructure
> 
> 
> duplicated, linked to, or moved to a Replicant Infrastructure Subproject
> wiki here:
> 
> https://redmine.replicant.us/projects/replicant-infrastructure/wiki
> 
> I feel like our wiki guidelines regarding the naming of pages[1]
> accomplishes the problem that a subproject wiki tries to solve, but
> perhaps someone else can think of good reasons for us to have two wikis.
> 
> I could perhaps see a benefit of having a subproject with only the
> issues and news enabled, but I haven't thought through the potential
> data fragmentation issues that might arise by doing this as much.
> 
> Are any problems solved by having infrastructure issues listed in a
> subproject instead of separated into its own Category on a unified
> Redmine project? If filtering is the perceived benefit, it seems to me
> that the filtering options for issues in our main Project are already as
> granular as they can get. It even includes the ability to exclude any
> Categories, including Infrastructure, that you don't want to see.
> 
> I seem to agree with this commenter's post on the subject, "[Redmine
> subprojects] are generally used for large projects when there are clear
> distinctions between both the groups of people working on different
> areas [and clear distinctions] between those areas".
> https://www.redmine.org/boards/1/topics/23075?r=23089#message-23089
> 
> Perhaps there will come a time to use subprojects, but it doesn't seem
> like we have the need for them currently.
> 
> It is worth noting that the Redmine project themselves don't use
> Subprojects: [2] https://www.redmine.org/projects
> 
> I should point out here that there is a redmine plugin[3] that adds the
> ability to make multi-project issues.
> 
> 2) Should we make it easier to find our web facing git repo?
> 
> The Redmine project seems to keep their projects's code in their redmine
> instance via the repository module:
> https://www.redmine.org/projects/redmine/repository
> 
> We have the Repository module turned off in our Redmine instance and
> instead use the FSF's infrastructure to host our web viewable git repo
> at git.replicant.us.
> 
> I'm in favor of continuing to use FSF's infrastructure to host our code,
> but it does make it more difficult to find our code in our Redmine
> instance than it is in Redmine instances that have a "Repository" tab
> that links to their git repo.
> 
> We also don't seem to have any direct links to git.replicant.us on our
> main wordpress site. I guess we sort of used to have these links before
> our git atom feed broke (which we still need to remove).
> 
> Would it be good to add a direct link to git.replicant.us on the top
> black banner of our main page where it says "Blog Wiki Tracker Forums"
> and also, if OSUOSL can do it easily, in between "Projects" and "Help"
> in the top left corner of all of the pages on our Redmine instance where
> it says: "Home My page Projects Help"
> 
> The easiest way for new visitors to our main page to get to
> git.replicant.us currently seem to require them to navigate to
> ReplicantSourceCode [4] which take more clicks than it really ought to.
> 
> 3) Plugins
> 
> There are a number of Redmine plugins that we should at least consider
> adding. Here's a few of them:
> 
> Agile - https://www.redmine.org/plugins/redmine_agile
> 
> a) Displays Redmine Issues as task cards on an Agile board
> 
> Checklists: https://www.redmine.org/plugins/redmine_checklists
> 
> a) adds checklists
> 
> Emojis - https://www.redmine.org/plugins/redmine_emojibutton
> 
> a) Enables the use of emoji codes
> 
> b) Insert emojis with new button in issue/wiki editor
> 
> Lightbox - https://www.redmine.org/plugins/redmine_lightbox2
> 
> a) Lets users preview image, pdf and swf attachments in a lightbox
> instead of requiring them to download images that aren't properly embedded.
> 
> People - https://www.redmine.org/plugins/redmine_people
> 
> a) Enables users avatars
> 
> b) Enables more granulated elastic permission rules,
> 
> c) Enables popup notification, reminders or warnings to a particular
> page, group of users or all users, including recurring notifications, or
> reminders
> 
> 4) I've closed all the 4.2 related tickets since we are no longer
> supporting that version. Is there a benefit to also closing Replicant
> 4.2 here [5] as was done with Replicant 1.5, 2.2, 2.3, and 4.0?
> 
> 5) Should we remove PDF files of issues? Here's an example:
> https://redmine.replicant.us/issues/1946.pdf I've noticed in the past
> that these .pdf files end up getting found by search engines and makes
> for an odd experience when one clicks on the link.
> 
> In Solidarity,
> kurtis
> 
> [0] https://www.redmine.org/versions/151
> [1]
> https://redmine.replicant.us/projects/replicant/wiki/DeveloperGuide#Wiki-guidelines
> [2] https://www.redmine.org/projects
> [3] https://www.redmine.org/plugins/redmine_multiprojects_issue
> [4] https://redmine.replicant.us/projects/replicant/wiki/ReplicantSourceCode
> [5] https://redmine.replicant.us/versions/39/edit
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osuosl.org/pipermail/replicant/attachments/20191008/220a2aa8/attachment.asc>